I am anticipating a battle over Subversion repositories: currently we have a single web application that was checked in as 3 main projects and 2 reports projects (when I started 6 months ago), is now up to 7 projects, and is expected to grow further.
It is obvious to me that this is just not right, that a compiled executable cannot cross a version-control boundary if you want to make reasonable use of the version-control system. It's impossible to have a single checkin for a single feature, and that seems essential to me.
But I feel like I'm hand-waving when I try to explain this. Does anyone have any references, for Subversion or in general, that lays out this principle and has some authority behind it? I've done some searching and am just not coming up with what I need.
There are a lot of options in Subversion how to structure your repository. See the discussion of repository layout in the documentation.
I would normally follow these rules:
The difference is the following:
Single project layout:
Repo MyProject:
trunk/
java/
src/
ruby/
doc/
...
tags/
rel1.0/
java (references the copy of java of revision xxx)
ruby (references the copy of ruby of revision xxx)
...
rel1.1/
...
branches/
feature_x/
java (references the copy of java of revision yyy)
...
Multi project layout:
Repo MyProjectBundle:
proj1/
trunk/
java/
src/
tags/
rel1.0/
java (references the copy of java of revision xxx)
...
rel1.1/
...
branches/
feature_x/
...
proj2/
trunk/
tags/
branches/
...
So the main differences are the following:
As a reference, I only have the quoted SVN red book, and of course one of the many answers in stackoverflow: Subversion Repository Layout