[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