Re: time to be serious about dropping CVS

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

On Sat, 2 Jan 2010, Christopher Faylor wrote:

> I think that if the project decides to move to git then it should move
> to git.  If that means that people who want to stick with CVS won't be
> able to easily make changes to the top-level configury then that's just
> something we have to live with.  Maybe I'm wrong but I don't think that

There isn't a "the project" here.  There are lots of independent projects.  
Each should choose its own version control system independently.  Each 
should choose who has write access independently.  Each should tag and 
branch independently.  If a contributor to one of those projects needs to 
tag and branch in some different way (from what would be normal for 
projects using whatever version control system it uses) because of the 
shared toplevel files, that project is doing something wrong.

You might decide that a toplevel.git (with shared toplevel files, 
libiberty etc.) that is the master for all these files is the best 
approach, rather than trying to make merges work in any direction.  But if 
so, I think it's best to treat toplevel.git like config.git (the 
repository with the masters of config.sub and config.guess): as a source 
of files to copy verbatim rather than something requiring special actions 
for every tag, branch etc. of users (submodules) or from which you can 
necessarily merge directly to users.  (And I don't know if there would be 
any use at all to the indirection involved in updating config.sub and 
config.guess by first copying from config.git to toplevel.git then from 
toplevel.git to individual projects.)  It may as a convenience be possible 
to merge directly from toplevel.git to some projects, but the design 
should expect toplevel.git to be used in other ways as well.

-- 
Joseph S. Myers
joseph@codesourcery.com