Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

[Larry McVoy]

On Tue, Apr 16, 2002 at 07:08:18PM -0500, M. R. Brown wrote:
> * Larry McVoy <[e-mail]> on Tue, Apr 16, 2002:
> 
> > > Please tell us that primary framebuffer/input/console development will
> > > continue in the CVS drop-in tree on SourceForge?  Bitkeeper is unable to
> > > support this (easier, more efficient) style of development.
> > 
> > Could you please explain why you think CVS is easier and more efficient?
> > Last I checked, BK was a superset of CVS, but could be used pretty much
> > identically to CVS if that's what you want.
> 
> A drop-in tree (also called "shadow trees" by Keith Owens of kbuild), is a
> small set of files intended to be applied against a larger parent body of
> code.  For example, a kernel subsystem or backend project (linuxconsole,
> LinuxSH, Linux-MIPS) will only maintain the minimal number of files that
> are specific to that backend, e.g. include/asm-mips/, arch/mips,
> /arch/mips64, etc. for any files local to the project.  

Ahh, OK, we're already working on this.  We call 'em nested repositories
and one of the problems they solve is exactly the problem you described.
Think of them as CVS modules, with a little more formality, and you're
about there.  They also solve a bunch of performance problems.

I tend to agree with your comments about not wanting the whole tree, to
some extent.  You are aware, of course, that your drop in may not work
if the rest of the tree has moved on.  So the drop in has a limited
life span in isolation.  With that caveat, drop ins are nice and we'll
have them before too long.  Unlike CVS, we like to be able to reproduce
the tree accurately so there is more work to do.

On your comments about CVS being less complex, I don't agree at all.
Almost all of the BK complexity is to handle problems CVS doesn't
handle at all.  Another way to say that is when you hit those problems
BK is much much less complex that CVS.  For example, a simple file
rename is a nightmare in CVS and a non-issue in BK, it just propogates.

If you want to eliminate learning "bk mv foo.c bar.c", just don't do
that and all of that complexity is never used.

I'll be the first to admit that BK is a big system, but it's no more
complex than CVS if you limit yourself to CVS-like operations.  And 
when you go beyond those limits, then BK becomes less complex to the
user just as CVS is starting to fall over.  Or am I missing something?
Have you read http://www.bitkeeper.com/cvs2bk.html ?  That covers the
translation.