Re: [fossil-users] fossil-users Digest, Vol 118, Issue 22
On Nov 21, 2017, at 1:24 PM, Ron W wrote: > > But, a "universal VCS adaptor" won't really be universal, so tool developers > will still end up supporting git, Hg and maybe SVN, so why would a tool > developer support Fossil-NG? Tool developers will ignore Fossil-NG to the same extent that they ignore Fossil today. The advantage is purely on the Fossil side: by allowing a tool to send us checkins via Git, they don’t *need* to support Fossil. If the user on the command line then says “fossil ui”, they should get a sane picture of all the commits their tool has been making via Git. If someone then clones the Fossil repository via its Git interface, they get a local Git checkout version of the remote Fossil repo, and I wish them all the enjoyment they may squeeze from that bitter lemon. :) > As for inter-operating with other VCSs, why is any given Fossil user using > Fossil instead of one of the others? Because the project’s creators and primary maintainers may not all agree on “best,” much less what the peanut gallery wants. I’d like to stop caring about what everyone else wants when I choose the project VCS. If they want to go use Git against my Fossil repository, I don’t care as long as the checkins come in well-formed, properly-commented, and on the right branch. I almost didn’t start using Fossil at all because of that concern. I *almost* switched from svn to git, purely for the network effect advantages. How many others have been making the same decision, but the other direction, and how many more will make the decision that way in the future? What if we could say, “Use Fossil for your own reasons, but know that we’ve got all the interop you could wish for if you need to use some other tool that isn’t Fossil-OG compatible.” That’s powerful stuff. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil-users Digest, Vol 118, Issue 22
On 11/21/17, Ron W wrote: > > For an individual commit (or small batch of commits), how much is the > translation overhead? > The overhead for a small batch of commits non-zero but it is manageable. A full clone, on the other hand, is too expensive. To give Fossil the ability to service clone requests from git or hg clients, it would be necessary to implement some kind of cache wherein all of the artifacts have been pre-translated. That means that the storage space requirements on the server would be multiplied by 2 or 3 (depending on whether your wanted to service just git or just hg or both). -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil-users Digest, Vol 118, Issue 22
On Mon, Nov 20, 2017 at 7:44 PM, wrote: > > Date: Mon, 20 Nov 2017 17:44:49 -0700 > From: Warren Young > Subject: Re: [fossil-users] Fossil-NG Bloat? > > On Nov 20, 2017, at 4:57 PM, bytevolc...@safe-mail.net wrote: > > > > Why add more complexity and bloat to the Fossil core? > > Because interoperability. One of the major arguments against using Fossil > is that it’s largely a one-way transition today, which messes up muscle > memory for both Fossil partisans and for partisans of other VCSes. > ... > Also valuable is that developer tool support generally goes git > hg > svn > > cvs > fossil, often stopping at git or hg. If Fossil could offer a Git > or Hg view of the same data and take pushes losslessly via that same > format, we wouldn’t have to keep blindly hoping that tool developers would > add Fossil support. > Between this and what the Fossil-NG page discusses, sounds like Fossil-NG would be more like a "universal VCS adaptor" - implement support for the Fossil API and you automatically get support for git, Hg, SVN, etc. (Similar to what the https://langserver.org/ project aims for coding languages.) But, a "universal VCS adaptor" won't really be universal, so tool developers will still end up supporting git, Hg and maybe SVN, so why would a tool developer support Fossil-NG? Maybe if Fossil-NG did a stellar job of supporting Hg and SVN APIs, tool developers would accept it as a replacement for directly supporting Hg and SVN. (I say Hg and SVN because their UIs are closer to Fossil's than git's UI is.) I suspect the best way to get interest in using a Fossil-NG "universal VCS adaptor" would be to provide a Hg-like API for use by tool developers. As for inter-operating with other VCSs, why is any given Fossil user using Fossil instead of one of the others? I use Fossil for its semantics, not its UI. Yes, there would be a certain convenience to having a Fossil-like UI to other VCSs, but it's not the same as Fossil itself. (At work, my team and I use both Fossil and SVN.) To my thinking, if a project's core team can agree on using Fossil, providing a git/Hg/SVN "shadow repository" for use by non-core contributors makes sense. Yes, the meta data translation is lossy, but the essentials can (be made to) get through. (For my team, fossil is our primary VCS with SVN as the shadow.) For an individual commit (or small batch of commits), how much is the translation overhead? If a git-sync-protocol (or Hg/SVN/other) "plug in" could be developed for Fossil (so we wouldn't have the overhead of external tools), I suspect the burden of keeping the main (Fossil) and shadow repositories sync'd would not be too unreasonable. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
