On Jan 13, 2006, at 9:57 AM, Ralf Stephan wrote:

Bob wrote

...

Well, it looks as though the Subversion beta test is beginning and we will be able to use it soon. Here is the notice that I received in the mail today. Note that it mentions the requirement of actually enabling it via the admins' page. Could one of the bosses turn it on? This is going to be so very nice. I already have TortoiseSVN installed in anticipation.

I want it, too. The recent commits would have been so much faster. Hello, Project Admins, are you alive?

Read the note.

:-)

It's actually a little scary if you've ever worked with CM systems.

"Separate but supposed-to-be-equal" parallel servers can be quite 'interesting'

We're looking at things now. Hopefully Mental will have some time to check for any of his concerns.

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)

Bryce Harrington wrote:

I've gone ahead and initiated the conversion. I had meant to only practice on just one of the modules, but it appears to be set up to do only the whole repository, unfortunately. There appears to be no way to cancel a conversion once it's already started.

So... Looks like we'll be converted to subversion within a few hours. Sorry if anyone has outstanding commits and has to patch them in manually.

Bryce

I guess that it is still in progress, because a checkout failed mid-stream. However, it looks like the URL for the entire repository is: https://svn.sourceforge.net/svnroot/inkscape

But likely people will not want or need the whole thing. The inkscape directory in particular is: https://svn.sourceforge.net/svnroot/inkscape/trunk/inkscape

Here is what a checkout looks like on Tortoise: http://www.inkscape.org/win32/tortoisesvn.png I made an empty "ink" directory to hold all Inkscapey things, and /ink/inkscape is the desired checked-out source directory.

bob (ishmal)

Everything checked out out fine. I did a win32 build with it here: http://www.inkscape.org/win32/Inkscape0601150117.zip

...and did a small commit. So everything is ok. Wonderful.

I guess that the "CVS" link on the front page needs to be "SVN" and point to the summary/svn page: http://sourceforge.net/svn/?group_id=93438

The viewcvs pages look great, too. http://svn.sourceforge.net/viewcvs/inkscape/

I did not see any Sourceforge docs on how to use key authentication. Maybe it's done in the .svn directory like normal, on the shell server.

bob

On Sun, Jan 15, 2006 at 03:56:47AM -0600, Bob Jamison wrote:

I did not see any Sourceforge docs on how to use key authentication. Maybe it's done in the .svn directory like normal, on the shell server.

Yeah, this is going to bug me. Honestly, I'm surprised they use WebDAV for authentication. It has a lot of limitations on the server side; it's much easier to do ssh-style commits.

On Sun, Jan 15, 2006 at 12:42:12AM -0600, Bob Jamison wrote:

If people use the command-line client, I think that they will need to do it something like this:

mkdir project_dir_name cd project_dir_name svn checkout https://svn.sourceforge.net/svnroot/inkscape/trunk/inkscape inkscape

"trunk/inkscape" selects the head of the current inkscape tree, and "inkscape" selects a directory to put it into. This is optional, but you will really want to use it, else the source will be rooted in the current directory.

By the way, the last attempt at checkout worked, so I think the migration is completed.

Excellent!

What is nice, is that there is no need for "anoncvs", and that a single repository can handle both use cases.

How has the speed been so far? I remember that was my #1 complaint with SF CVS.

Bryce

On Sun, 2006-01-15 at 00:18 -0600, Bob Jamison wrote:

I guess that it is still in progress, because a checkout failed mid-stream. However, it looks like the URL for the entire repository is: https://svn.sourceforge.net/svnroot/inkscape

But likely people will not want or need the whole thing. The inkscape directory in particular is: https://svn.sourceforge.net/svnroot/inkscape/trunk/inkscape

I'm wondering whether we should give each module its own trunk and branches. I did that for the The Ruby Grammar Project, but I'm still not sure whether that's a good idea.

Thoughts?

-mental