Re: Moving to an alternate VCS

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

On Thu, 3 Feb 2005, Mike Stump wrote:

> On Feb 2, 2005, at 9:32 PM, Daniel Berlin wrote:
> > Therefore, I believe we should seriously start considering and talking about
> > a migration path to a version control system we can work with in the next
> > year.
> 
> To be concrete, how about one week after 4.0.1 or 4.0.2 is released?  We don't
> want it just after 4.0.0, as we should have a small influx of bugs that we'll
> want to spend time on instead of playing with the infrastructure.  Post 4.1
> doesn't seem to offer any advantages that I know about, are there any that
> people can think of?

Is there a need to delay until after 4.0.0 if it seems to be ready before 
then?

If there is a reliable repository conversion procedure (i.e. known good 
cvs2svn command line options to deal with those tags that are tags in some 
files and branches in others, such as that posted to overseers a while 
back), and the scripts in maintainer-scripts and contrib are fixed (i.e. 
patches are ready to check in once the conversion goes live - note that 
the updated gcc_release may need copying to old active release branches), 
and the scripts called on checkin (that do auto-checkout, gcc-cvs etc. 
messages, messages to bugs etc.) are fixed, and web page updates are 
ready, and the updated rsync configuration for people to rsync the new 
repository and any backup system changes are ready, and savannah is ready 
to mirror or we are ready to take back the load of anonymous access for a 
while, and the lack of uberbaum for a while isn't considered a critical 
problem, why not make the conversion for real and reap the benefits even 
before 4.0.0 is released (and thereby get the release script tested 
through the 4.0.0 prereleases)?

As I understand it the conversion procedure would be something like, after 
suitable testing with trial conversions so people can see how svn works 
for them:

* Ensure updates to scripts, web pages, etc. are ready to go in once the 
conversion is done.

* Put up a conversion status web page (e.g. svn.html, which would later 
become the equivalent of cvs.html).

* Check in a file README-MOVED-FROM-CVS-TO-SVN or similar in the toplevel 
source directory, which explains the conversion and points to that page, 
so people updating old checkouts get a good idea of why they no longer 
relate to current development.

* Stop all write access to the repository.  Put a tarball in 
old-releases/old-cvs on the FTP site alongside the old GCC2, libgcj and 
libstdc++ repositories.  Keep the repository available read-only 
permanently afterwards so old cvsweb URLs continue to work and people can 
still diff old CVS trees with development work in them.

* Run the final conversion (a rather time-consuming step).  Put the 
results up with write access.  Check in the prepared updates to scripts 
and web pages and make sure that the website has updated OK.  If 
applicable, ensure savannah has rsynced the new repository.  Send 
announcement to gcc and gcc-announce lists.

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