Source code control

Bryan O'Sullivan bos at serpentine.com
Mon Jan 5 15:32:00 CET 2004


Not to bang the BK drum, but I'd hate to see the arguments for or
against it misrepresented.

On Mon, 2004-01-05 at 06:15, Eric W. Biederman wrote:

> > In the end, what does arch do better than bitkeeper? 
> 
> - Merging, arch has several methods.

BK's merging support is, for what it's worth, by far the best I have
seen.  It does most merges automatically that tools like CVS just dump
you into vi for.

> - Branches, with arch you don't need multiple copies of your archive.

BK has pretty cheap branching support.  It uses a tree of hardlinks if
that's what you want, so you just end up paying in inodes.

> - Distribution.  All you have to do to export an arch repository for
>   all the world to see is to point an ftp or http server at it's
>   directory.

BK has a built-in server that provides the same facilities.

> - Renames.  Since arch does not revision control the files individual
>   but a change at a time you don't get into awkward situations with
>   the SCCS version control file named differently than the file itself.

BK supports renames and metadata changes (file modes, mostly) perfectly
well.

BK is pretty slow on a large tree.  However, it's several thousand (!)
times faster than arch in most cases, which is by design just abominably
slow at even the most trivial of common operations.

> As for the Linux kernel half the developers don't use bk for
> lots of things including at the moment Andrew Morton the 2.6
> maintainer.

One solid reason for this is that BK doesn't have good GNU patch
handling support.  You can import a GNU patch into BK, no problem, but
it's a huge PITA to then manage successors to that patch as their
maintainer issues them.  You're basically left in manual merge hell.

Andrew wrote his own set of scripts, which have since taken on a life of
their own, to handle a pile of patches against a tarball.  This works
better than BK for a loosely-coupled world in which everyone flings GNU
patches around.  If you have a tighter world in which 90% of people deal
in terms of BK patches, BK is a lot easier to work with than the patch
scripts.

On the other hand, there's a lot to be said for open source software in
this realm.  Larry is perfectly happy to tell paying customers to fuck
off (and in approximately that language, too, as Ron can probably
attest) if he doesn't want to implement a feature they're requesting. 
The flip side is that arch is about a decade away from being as
performant and mature as BK is today.

	<b




More information about the coreboot mailing list