Re: Moving to an alternate VCS

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 7 Feb 2005, Walter Landry wrote:

> This is not so clear.  It will certainly make it easier than it is
> now, but subversion requires everyone to have their branch on the main
> server.  It discourages experimental, throw-away branches because you
> are cluttering up the namespace for everyone.

I don't think the discouragement of experimental branches is significant; 
we haven't needed formal namespace rules yet, and explicitly allow anyone 
with CVS write access to create a branch for any development as long as 
the code is assigned to the FSF as usual.  Discouraging branches that are 
literally throw-away - ones on a private server which has gone away in ten 
years' time when people are reading old list discussions of the branch and 
want to look at the code for potentially relevant ideas - is in my mind a 
good thing.  Having all the various distributor branches visible on the 
central server so anyone can see what patches different GCC distributors 
are using, see new development through the gcc-cvs mailing list, etc., 
also seems a good idea.

I understand Subversion makes it even easier to ensure long-term 
availability and integrity through providing the necessary hooks for 
multiple offsite audit trails of every repository change through a 
gcc-cvs-patches mailing list (as requested in bug 1634).  Mailing lists 
indicating all changes on whatever branch only seem to make sense 
naturally with a central server.

Insofar as distributed systems mean parts of development don't appear on a 
central server, as opposed to simply increasing the operations developers 
can perform offline but keeping all changes centrally, I don't see the 
advantages for FSF GCC development.  (There are of course uses of private 
development which needs to be private, for a while or indefinitely, but I 
don't think they are relevent for the version control system used for FSF 
GCC.)  The discouragement of development seems hypothetical; long-term 
availability and integrity issues are real.  No GCC commits were lost in 
the system restore from backup a few days ago.  Subversion seems a natural 
move which can improve reliability even further and does not require 
process changes - remember the principle of GCC patch review, which I 
would apply to almost any change to anything whatsoever, that changes 
should be minimal and do one thing only, so development process should not 
be changed at the same time as version control system.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)