mental@...3... wrote:
Quoting Ralf Stephan <ralf@...748...>:
I want it, too. The recent commits would have been so much faster. Hello, Project Admins, are you alive?
We need to do some sort of transition -- we can't just turn on SVN and keep working.
So we need a transition plan first.
-mental
From what I glean by reading, it looks like enabling SVN service does only that ... enables it. It only provides an empty repository.
I would suggest doing what GCC did. Make a Subversion copy of the CVS repository that people can experiment with. Give people a cutoff date (midnight on Saturday/Sunday?) to prepare for the transition. At that point, someone makes an official CVS backup for safety, migrates over again, and discontinues CVS.
For safety: make a branch, and migrate the branch. Then people have a point of reference in CVS for where to stop. Then CVS BRANCH_X could equals SVN Revision #NNN. I would think that with as many commits as Inkscape has had in its current CVS repository, the SVN revision number would be rather high. Unless, maybe, we want to cut off CVS history and start fresh, keeping the CVS repos for its history. Maybe a good opportunity.
Note the offer of human intervention. I don't really think that this is that scary... people just need to know what is happening. I have migrated from CVS before using cvs2svn, and it is very easy. If you screw up, you can just delete the SVN module directory (an impossible concept in CVS) and try again.
Also note that there is no anoncvs mirror for Subversion. One repository does both anon read access and project read/write access.
There are several directories with which to practice before the inkscape module itself: http://cvs.sourceforge.net/viewcvs.py/inkscape/
bob (ishmal)