I am reforwarding this as it got dropped by a bunch of 'naughty language' filters ...
ron 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 > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
