[PEAK] Moving to Subversion

Phillip J. Eby pje at telecommunity.com
Tue Jun 28 23:50:00 EDT 2005


After more investigation, it seems like it's going to be easier to just 
move to Subversion than to do all the CVS repository munging I described 
last night.  So much easier, in fact, that I've already done a prototype 
migration:

ViewCVS:  http://svn.eby-sarna.com/

Anonymous SVN:
     svn://svn.eby-sarna.com/svnroot/wsgiref
     svn://svn.eby-sarna.com/svnroot/PEAK
     svn://svn.eby-sarna.com/svnroot/PyProtocols

If you have a login to the box (i.e., if you're Ty ;) ), you can use 
svn+ssh: URLs instead of svn: URLs to get write access, although you may 
have to modify your .bashrc to set a path that includes svnserve.  (I had to.)

I don't have commit messages implemented yet, although if you're on the 
source-changes mailing list you might think otherwise with all the test 
mails flying by.  Those are actually being generated by svn2cvs, which is a 
reverse migration script that copies Subversion changes back into 
CVS.  This will be what we'll use as our safety line in case we have to 
abort the migration and don't want to redo commits.

It also means that I won't have to write a script to send commit messages 
right away, because the CVS commit scripts take care of that, although they 
generate links to the CVS revisions, not the SVN ones.  But, I'll want to 
switch that over to Subversion-specific commit messages pretty soon.

Finally, it also means that I'll be able to leave all the current CVS 
infrastructure in place for people who aren't quite ready to make the switch.

I haven't decided yet when to actually "flip the switch" and begin using 
SVN officially.  My migration scripts seem to be in order, and everything 
seems to work, so I might do it as soon as tomorrow evening, or as late as 
the weekend depending on how things go.  Things have been mostly going so 
well that I might be tempted to add more features, like maybe play with 
Trac (combination wiki/case tracker) and see whether I want to set ones up 
for each of the projects that's getting split off.

On the other hand, I'm really anxious to start breaking the really 
"external" stuff out of PEAK (wsgiref, protocols, dispatch, fcgiapp, 
ZConfig, etc.) so I might want to hold off on getting fancy, except maybe 
to check whether Trac makes any assumptions about your repository layout 
(e.g. that branches/trunk/tags crap) in which case I might need to rethink 
my current plan of matching our CVS tree exactly and adding _BRANCHES and 
_TAGS directories at the root for future use.




More information about the PEAK mailing list