On Mar 24, 2009, at 10:52 PM, bharder wrote: > > http://keithp.com/blog/Repositor_Formats_matter/ > > Would anybody knowledgeable care to comment about fossil in this > light?
Both Havoc's original remarks (in favor of subversion) and Keithp's rebuttal (in favor of Git) are old. Fossil existed but was not really a factor when these remarks were written. It is not sufficient to compare fossil to subversion or Git directly. Fossil should be compared to subversion+trac or to git+trac, since fossil contains both the version-control feature (provided by subversion/git) and the wiki and bug tracking provided by trac. This is a key point that both commentators overlook. Version control is important, but it is not the only thing you need for managing a project. It is vitally important to maintain visibility into the status of the project as well. To put it another way, it is important to maintain good "situational awareness" with respect to the project - to know what is changing, who is changing it, and why. That capability is not provided by git or subversion - you have to supplement them with additional tools. But the capability is inherent in fossil. And that is a key differentiator. At a fundamental level, fossil uses the same storage model as Git: Unmodified files named by their SHA1 hash. In the current implementation of fossil, the files are stored in an SQLite database using both delta and libz compression. Git stores the files as individual files on the filesystem, at least until you compress them for archival purposes (a separate step.) Fossil does the compression as you check-in. This means that check-ins might take a little longer, but we are only talking a second or two. For storage efficiency in fossil, see (as an example) http://www.fossil-scm.org/fossil/stat for the latest statistics on the fossil self-hosting repository. 12:1 compression is pretty good. I do not have information on the network efficiency of git versus fossil. However my understanding (correct me if I am wrong) is that git does not use delta compression when transmitting updates over the wire. Fossil does. This would suggest that fossil is more efficient at synchronizing repositories. But I have never measured that. I would welcome actual measurements from people included to make them. Finally, Havoc is right, I think, that user interface matters. It is important that your CM system stay out of your way. The CM system should not require extra though. Use all your brain cycles to work on the project itself - do not waste them having to figure out your CM system. To this end, whatever CM system you use needs to be as simple and intuitive as possible. Every system has a learning curve, of course. But we want the learning curve to be as short as possible, and once one starts using the system, you shouldn't ever have to think about it again - it should "just work". Time spent messing with configurations and access permissions and "publishing" branches is time that you are not making productive enhancements to your project. My guess is that Havoc would like fossil if he know about it.... D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
