Re: The essential problems of moving from CVS

["D. Richard Hipp" <drh%hwaci.com@localhost>]

On Jan 18, 2010, at 12:13 PM, bharder wrote:
> I've cc:'d drh, guessing he might be interested in at least watching
> fossil (potentially) being considered for such a sizeable project as
> NetBSD, and perhaps commenting on it's suitability.


Greetings all NetBSDers.  I am Richard Hipp, the designer and  
maintainer of Fossil (and SQLite) and I would like to offer my views:

Fossil was created by me for my needs.  It wasn't really designed to  
handle a project like NetBSD.  But on the other hand, as with many  
software projects, Fossil has ended up being used successfully in ways  
far different from what it was designed for.  Even I'm using it  
differently from what I original envisioned.  So Fossil might work  
well for NetBSD.  Or it might not.  I don't know your workflows, so I  
can't really say for sure.  What I can do is try to give you some  
insight into the differences between Fossil and other VCSes.

Distributed VCSes (DVCSes) have many advantages over more traditional  
central-server VCSes like CVS and subversion.  No doubt you've already  
been over that ground.  But DVCSes also have some big disadvantages.   
DVCSes encourage lots of branching.  And they force you to do lots of  
merging.  And DVCSes do not have a central place to go look for all  
the action.

Fossil tries to take a middle approach.  Fossil allows you to have a  
central server (or two or three - see http://www.fossil-scm.org/fossil/doc/tip/www/selfhost.wiki 
 for information on the 3 geographically distributed self- 
synchronizing servers that host Fossil itself) where all the action  
resides.  But Fossil also supports disconnected operation, so that  
check-ins and check-outs (and bug-tracking and wiki managements) can  
take place offline, in airplanes, or wherever else you work and wifi  
is unavailable.  The servers tend to keep all developers on the same  
branch so that everybody is working on the same code base and there  
doesn't need to be a central merge-guru whose only job is to merge  
together diverging changes from all the other developers.  Fossil make  
it easy to create branches when you want to (release versus  
development, for example) and branches are way easier to manage than  
in CVS and SVN.  But, unlike git and hg, Fossil allows multiple  
developers to be working on the same branch at the same time.  In that  
way, Fossil is much closer to CVS than the other DVCSes out there.

Other nice things about fossil:  (1) The whole thing is a single  
executable.  There are no dependencies.  You can run it from within a  
chroot jail for security, if you want.  And the executable is cross- 
platform (with recompilation) so that you can work from a variety of  
platforms. (Though, I suppose, yall will work exclusively from NetBSD  
- I'm cool with that.)  (2) The client/server communication is over  
HTTP with proxy support so that it works from behind restrictive  
firewalls.  We've been told by some users that Fossil is the *only*  
VCS (distributed or otherwise) that they can get to function on the  
network of their employers.  (3) The sync protocol is amazingly  
efficient.  SQLite used to be a 320MB CVS repository, but since being  
moved to Fossil, can be cloned using only 13MB of network traffic.  A  
typical check-in for SQLite uses about 3-4KB of HTTP traffic - which  
is small enough that SQLite is easily usable from a dialup modem.   
(That might be useful if you have to work from a low-bandwidth  
wireless connection.)

FWIW, I think the "fossil ui" feature is really cool.  I use that a  
lot.  "fossil ui" was not part of the original design of Fossil.  It  
was an idea I had one day.  But that idea has changed the way I do  
software development.

Git and hg are faster than Fossil I'm told.  I don't much care,  
though.  Fossil is "fast enough".  A check-in normally takes a second  
or two.   Are you such a hurry that that is too slow?  Part of the  
slowness is that Fossil does lots and lots of checksumming and cross- 
checking to make sure that everything in the repository is valid and  
recoverable.  That's a defense against bugs.  I'd much rather my check- 
in take an extra 500 milliseconds and know that my work is safe, than  
go a wee bit faster and always have the nagging worry that I might hit  
some obscure bug that is going to wipe out the last days work.

I suppose my biggest concern with Fossil and NetBSD is how Fossil  
might scale.  We use Fossil on projects with a 1GB or larger check-out  
and with thousands and thousands of files.  But I didn't really design  
fossil for truly huge projects.  How big is NetBSD?  How large is your  
CVS repository?  How many check-ins do you do per day?  How many  
developers do you have?

I'd be thrilled if yall give Fossil a try.  If you run into any  
scaling issues, I'll be happy to work with you to try to resolve  
them.  But also please understand that if you want to go a different  
route you will not hurt my feelings.  Fossil is there if you want to  
use it, and I'm happy to help you with it, but I really wrote it for  
myself.  And it meets my needs well.

I'm not on the NetBSD mailing list, so CC to me on replies is  
appreciated.

D. Richard Hipp
drh%hwaci.com@localhost