Diasparsoft Logo Let's write software that people understand.

Home | Contact

Training

JUnit support

Outsourcing

The work that Diasparsoft did for us was outstanding. We are now using the software on a daily basis and their work could well have a dramatic impact on the Reds' organization in the near future. —Cincinnati Reds Baseball Club.

Publications

Tips & Tricks

Diasparsoft Toolkit

What is Diaspar?

Interesting Bits RSS

Home » Archives » July 2004 » Subversion for CVS users: Multiple repositories

[Previous entry: "A fresh, new look!"] [Next entry: "Subversion troubles: SVN+SSH=PITA"]

07/20/2004: "Subversion for CVS users: Multiple repositories"


I have been switching from CVS to Subversion, now that the latter has attained full v1.0 status. Along the way, there are always headaches. Today's lesson has to do with the difference between CVS modules and a Subversion repository.

There are a few lessions to learn here.

  1. Start svnserve with the same argument for the -r switch every time. Paths within the repository are relative to the argument passed to this switch, and the default value is the root of the drive running svnserve. Changing this is a recipe for confusion. (Dude, where are my files?)
  2. It looks like it is easiest to run one repository per server machine. Someday I will experiment with the Apache integration or with multiple servers on multiple reports, but for now, one repository per server machine is easiest.
  3. As a result of the preceding point, import each project into the repository as a separate folder. That means svn import /path/to/working/copy svn://host/svnroot/whatever/ProjectName. Without ProjectName, Subversion imports the files into the root of the repository, which is weird.
  4. Subclipse seems not to do the preceding, so import projects from the command line, and not through Eclipse's "Share Project" option.
  5. If you have multiple repositories running, then let that be one repository per related group of projects. That is, if you have 6 projects in your IDE that relate to one another, then put them in the same repository; otherwise, have one project per repository. It seems wasteful, but remember that Subversion creates revisions of trees, and there's no reason to track revisions across unrelated trees!

That'll do for now.