On Mon, Nov 20, 2017 at 7:44 PM, <fossil-users-requ...@lists.fossil-scm.org> wrote: > > Date: Mon, 20 Nov 2017 17:44:49 -0700 > From: Warren Young <war...@etr-usa.com> > 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
