On Mon, 20 Nov 2017 17:44:49 -0700 Warren Young <[email protected]> wrote:
> On Nov 20, 2017, at 4:57 PM, [email protected] 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. This seems more like a complaint about the user interface. > 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. Of course. So next up, Subversion should implement native Git support, and Mercurial should implement native CVS support. > > 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. The idea being proposed appears to be that Fossil repositories should be able to store artifacts in multiple different formats, which will only be a disaster since the "legacy" Git/SVN/CVS clients cannot read that kind of repository anyway. Thus, this idea is just bloat. > > 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. You will also find that tool developers may just get rid of existing Fossil support (if it ever existed) because oh well, Fossil can support Git so no problem. > > 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. Adding tightly integrated support for other VCS software may just give you an apples-to-gorillas comparison instead, since the overhead of the proposed feature set will slow Fossil down even more and skew the result. Let's face it, the SQLite single-file storage mechanism has a number of other advantages over the pile-of-files methods, even if performance isn't one of them. There are other means of optimisation that can be used first. Profiling and optimising the most frequently called routines will help. Not coding like it's 1989 and use modern C99/C11 (eg. postpone variable declarations, declaring variables in a for(...) loop, uint_XX_t, inline, etc) will also help. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
