subversion

[me at mattgillen.net (Matthew Gillen)]

Peter Kahle wrote:
>(copy-on-write), so the typical repository looks either like:
> 
> /branch
> /branch/Project1
> /branch/Project2
> /tags
> /tags/Project1
> /trunk
> /trunk/Project1
> 
> OR
> 
> /Project1
> /Project1/branch
> /Project1/branch/Some branch name
> /Project1/tags
> /Project1/tags/Version1.0
> /Project1/trunk
> /Project2
> /Project2/branch
> /Project2/branch/Some other branch name
> /Project2/tags
> /Project2/tags/Version2.0
> /Project2/trunk
> 
> Pick one, and stick to it. I almost always use the first option, but now
> that I think about it, I think I'll use option 2 from here on out, since
> it would make it easier to dump the full history from one project to
> move to another repository. Another option is just to use a separate
> repository for each program.

We've used option 2 quite a bit, and it works pretty well.  Our use case
that the projects are related (hence in the same repository), but separable
and have different developers.   So it makes sense for each project to have
it's own isolated branch trees, etc.

Subversion also has a nice way of saying: "When checking out Project 2, also
check out Version1.0 of Project 1".  It's called 'externals' (
http://svnbook.red-bean.com/en/1.1/ch07s04.html ), and is quite a step up
from the CVS "vendor branch" technique.

> Oh, and it's the default now, but using the "fsfs" (file system file
> system) back-end is MUCH better than the "dbfs" which has a tendency to
> break on bdb upgrades, even if you take a small hit in speed. Otherwise,
> do regular dumps (svnadmin --dump <repository url>) or you may get stuck.

I'll second that.  The fsfs backend is also NFS-safe (ie it's safe to keep
the repo on a filesystem that is NFS mounted by many clients, and the
clients then use a local file:///mounted/nfs/repo/ url instead of a
svn+ssh://server/ URL).

Matt