tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: The essential problems of moving from CVS

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 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

Home | Main Index | Thread Index | Old Index