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. I’ve had people wish for Git access to my largest public Fossil repository multiple times, and it’s got a pretty small community. I imagine providers of large public Fossil repos get this complaint all the time. fossil export solves this to only a limited extent. The translation is lossy in the primary direction and even lossier in the reverse direction. I assume the idea here is to reduce the impedance mismatch between the formats. 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. There’s precedence for having multiple backends, most notably svn. If nothing else, this will let us make apples-to-apples performance comparisons. Is git’s speed advantage due in any meaningful part to its use of a pile-of-files repo format, or is SQLite’s single-file indexed declarative access approach superior? We can largely only speculate today. With this change, we can KNOW. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
