From: RaeNye <raenye_at_netvision.net.il>
Date: Fri, 22 Dec 2006 02:24:42 +0200

If syncing the SVN with current CVS is easy (scriptwise), I suggest the
following:
1. Setup SVN based on current CVS. No commit access yet, with the exclusion
of a CVS->SVN sync script run daily (or maybe after each commit).
2. Convert scripts to work with SVN one at a time. We can easily compare cvs
version and svn version of the same script.
3. Once we're sure the SVN infrastructure works, give SVN commit access to
CVS committers and make CVS read-only.

The advantage of this is that we have a fully working infrastructure at any
given point, and we can replace components one-by-one.

My 2 cents,
R.

-----Original Message-----
From: rockbox-dev-bounces_at_cool.haxx.se
[mailto:rockbox-dev-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Thursday, December 21, 2006 1:25 PM
To: Rockbox Development
Subject: going SVN

Hey

My suggestion on how to proceed on this:

1 - We set a date (I suggest January 8th 2007) when CVS commits are no
longer
     allowed. We can still provide that CVS as read-only.

2 - We then convert the then current CVS to SVN and hand out new passwords
to
     people with commit access. We also move the repo to a different server
     when we do this, to provide MUCH better bandwidth and CPU performance.

3 - I convert the cvs build server script to use svn instead. It is a quick
     fix, but since it will also require that all build servers have the
     Rockbox repo checked out with svn and have the svn binary in their
paths,
     we'll need to poke on all server admins to stay tuned and be ready for
     this.

4 - the "recent cvs changes" script (cvs2html) will be scrapped and we write
     a new one. Here's an apportunity for someone to step forward and
provide
     a replacement that can present a similar table that we do now, but use
svn
     to get the info. svn does have easier output so such a script would
need
     a lot less voodoo than it needs with cvs. (I can hand out the username
=>
     realname translation table.)

5 - we install viewcv instead of viewcvs on the (new) server to offer a
     browser view to the repo

6 - whatever is broken by then can be fixed, one script at a time until
we're
     back on track again

I figure we rather do this and bear with a few days of unstable source
repository services, than just let this issue drag along for much longer.

Feel free to point out any major flaws in my thinking.

--
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/

Received on 2006-12-22