Re: source mgt. requirements solicitation

[Linus Torvalds <torvalds@transmeta.com>]

In article <20021215014255.GA1146@doctormoo> you write:
>
>In GCC, we've been known to lose development history when we merge a 
>branch, and merging branches has been incredibly painful.  So I'm not
>sure merging forks is actually harder; merging branches may be. ;-)  

Heh. That's a sad statement about CVS branches in itself.

>Fork merges get submitted as a series of patches (which then need to get 
>approved), and associated ChangeLog entries.  They go in pretty cleanly. 

This is actually not that different from the "old" Linux way, ie the SCM
does _nothing_ for merging stuff. It certainly worked fine for me, and
it's how about half of the Linux developers still work.

The advantage of the SCM-assisted merges is really that when you trust
the other side, it becomes a non-issue.  So to some degree you might as
well think of a SCM-assisted merge as having "write access" to the tree,
except it's a one-time event rather than a continuing process (but
unlike CVS write access it doesn't _need_ to be constant, since both
sides have access to their own SCM structures on their own, and don't
need to merge all the time).

>The fork developer can track his/her own internal change history however 
>he or she likes, but generally will submit an 'expurgated' history for 
>merging, devoid of the false starts, which makes the patches a lot easier 
>to review.  This is in fact an argument in favor of losing 
>development history.  ;-D

We do that with BK too, occasionally. It's sometimes just cleaner to
create a new clone with a "cleaned up" revision history. It's not needed
all that often, but I certainly agree that sometimes you just don't want
to see all the mistakes people initially made.

It's also needed in BK for things like merging from two totally
different repositories - you can't auto-merge just one fix from a
Linux-2.4.x BK tree into a 2.5.x BK tree, for example (when you merge in
BK, you merge _everything_ in the two repositories).  So those have to
be done as patches, kind of like the clean-up thing. 

>>Yet it is the _cheap_ branches that should be the true first-class
>>citizen. Potentially throw-away code that may end up being really 
>>really useful, but might just be a crazy pipe-dream. The experimental 
>>stuff that would _really_ want to have nice source control.
>
>Interestingly, I tend to find that this sort of stuff is exactly what
>*doesn't* need source control; source control simply obscures the 
>process by exposing too much development history, much of which has no 
>relevance to the current version.  Or did you mean code that already 
>works, and is being refined, rather than code in the 'rewrite from 
>scratch every two weeks' stage?

I personally find that _most_ changes by far tend to be fairly small and
simple, and take a few hours or days to do. Yet at the same time, you
want to have access to a lot of the SCM functionality (commit one set of
changes as "phase 1 - preparation", "phase 2 - update filesystems" etc).

At the same time, the tree often doesn't work until all phases are done,
so you do NOT want to commit "phase 1" to the CVS head - and creating a
CVS branch for something that is really not a big project is clearly not
something most people want to do. The pain of the branch is bigger than 
it's worth.

And THIS is where the distributed repository nature of BK really shines.
It's a totally everyday thing, not something odd or special. You can
work in your own repository, with all the SCM tools, and document your
changes as you make them (and undo something if you notice it was
wrong). Yet you do _not_ need to pollute anything that somebody else
might be working on.

And then, when you're ready, you just push your changes to some other
tree (in BK it's an atomic operation to push _multiple_ changesets), and
tell others that you're done.

See? I'm not talking about a big six-month project.  I'm talking about
something that potentially is just a few hours.  You might do your first
cut, and check it into your tree, verify that it works, and then you
might want to go back and make another few check-ins to handle other
cases. 

In gcc terms, let's say that you change the layout of something
fundamental, and you first make sure that the C front-end works. You
check that in and test it (on the C side only) as one stage. Only when
you're happy with that do you even _bother_ to start editing the C++ and
other front-ends.

With distributed trees, it's easy to make these kinds of multi-stage
things. Because nobody else sees what you're doing until you actually
decide to export the thing. With CVS, it's a total _disaster_ to do
this (and the way everybody works is to do all the work _without_ SCM
support, and then try to do one large check-in).

			Linus