Moving from CVS to SVN - Swimming Around

Shouting Into Space

日期

Calendar

Quicksearch

Support Wikipedia

Thursday, March 17. 2005

Posted by Latcarf in SCM

Comments (0)
Trackbacks (0)

Moving from CVS to SVN - Swimming Around

It's become time again for me to revisit my organization's desire to move from CVS to Subversion. I've gotten out a few releases of our products recently and with that work out of the way, I'm getting back to swimming around in Subversion.

This is the third installment in my ongoing detail of the move to Subversion. In the first installment of this series, I spoke about my organization's interest in using Subversion instead of CVS. In the second installment, I detailed how I installed Subversion on Mac OS X (Panther) and how I initiated the process of converting some of our CVS repositories. In this installment, I will go into further detail about interacting with the "mock" Subversion server and the pilot project repositories.

I started reading: Pragmatic Version Control Using Subversion. It is a good place for practical information on using Subversion. I'll reference that book where I detail something I've done because of information I found there.

Between the time I first installed and setup Subversion and now, I decided that WebDAV was not the best way for my developers to access the svn repository. We already have a dedicated CVS server (actually a Mac OS X 10.3 machine) that has user accounts for all 10 of my developers. They currently use ssh to access CVS on that server and since that infrastructure is already set up, I decided that the svn+ssh protocol is the best way for us to access Subversion. This way, I won't have to manage a separate set of Apache usernames and passwords.

I created a new 'svn' group using the NetInfo Manager (/Utilities/NetInfo Manager), and added the developers to that group. I realized that there was something wrong with the permissions on my repository directories so I corrected it by entering the following (where "repo_path" is the path to my repository directories):

$ sudo chgrp -R svn repo_path ¬
$ sudo chmod -R 770 repo_path ¬
$ sudo chmod g+s repo_path/db ¬

According to the "Pragmatic" book, incorrect permissions on repository directories is the most common cause of Subversion repository lock-ups (since BerkelyDB sometimes needs to create new files). Hopefully now, I won't run into that problem.

I did my first checkout of the source via the Terminal (/Utilities/Terminal). I issued the following commands (project and host names have been changed to protect the innocent

$ cd; mkdir -p Documents/work/svn_test ¬
$ cd Documents/work/svn_test ¬
$ svn co svn+ssh://myhost.local/Users/Shared/\ ¬
$ svn/myproj/trunk myproj ¬
A myproj/my_dir/source.mm
...

(I broke up the lines to make it easier to read here)

The first thing I noticed is that the few files I have that still have resource forks no longer had resource forks. That's a problem! >:-o I think they were really lost during the conversion from CVS to SVN since the cvs2svn script actually checks out and checks in the files. I'll have to find a fix for this problem eventually or the Subversion move will be impossible.

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

No comments

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information?