Re: source mgt. requirements solicitation

[Nathanael Nerode <neroden at twcny dot rr dot com>]

Linus said:
>But the point is, the "CVS mentality" means that a fork is harder to 
>merge than a branch, and you often lose all development history when 
>you merge a
>fork as a result of this (yeah, you can do a _lot_ of work, and try to
>also merge the SCM information on a fork merge, but it's almost never 
>done because it is so painful).
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. ;-)  

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

>And the "CVS mentality" totally makes that impossible. Subversion seems 
>to be only a "better CVS", and hasn't gotten away from that mentality, 
>which is sad.
Well, Subversion aims only to be a "better CVS", according to its 
mission statement.  Frankly, a 'better CVS' would help a lot, for GCC.
The GCC development plan actively encourges the use of branches for most 
development (as opposed to bug fixes).  But CVS makes it less than easy 
and less than fast.

In addition, CVS makes setting up an anonymously accessible repository 
into a pain in the neck; in this case 'forking' to your own repos has a 
stupid and unnecessary overhead.  Theoretically this should be easier 
with Subversion, so there should be more private repositories floating 
around.

I think that there are a few very small features which would make 
Subversion fairly effective for the typical use case of "I have a 
branch, I track a particular 'mainline', and intermittently I merge into 
the mainline", even if the 'branch' is in a different repos from the 
'mainline', and the 'mainline' is a branch.  But I said that on the svn 
list...

>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?

--Nathanael