Rockbox mail archiveSubject: RE: going SVN
RE: going SVN
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
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,
[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
My suggestion on how to proceed on this:
1 - We set a date (I suggest January 8th 2007) when CVS commits are no
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
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
we'll need to poke on all server admins to stay tuned and be ready for
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
a replacement that can present a similar table that we do now, but use
to get the info. svn does have easier output so such a script would
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
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