[Etherboot-developers] Re: Source code control
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'
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
> 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
> 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.
> 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
More information about the coreboot