[Etherboot-developers] Re: Source code control

ron minnich rminnich at lanl.gov
Mon Jan 5 20:51:01 CET 2004

I am reforwarding this as it got dropped by a bunch of 'naughty language' 
filters ...


On Mon, 5 Jan 2004, Bryan O'Sullivan wrote:

> 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 f@@@
> 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
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

More information about the coreboot mailing list