Subversion revision number across multiple project

Question

When using Subversion (svn) for source control with multiple projects I've noticed that the revision number increases across all of my projects' directories. To illustrate my svn layout (using fictitious project names):

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

When I perform a commit to the trunk of the Ninja Program, let's say I get that it has been updated to revision 7. The next day let's say that I make a small change to the Stealth Application and it comes back as revision 8.

The question is this: Is it common accepted practice to, when maintaining multiple projects with one Subversion server, to have unrelated projects' revision number increase across all projects? Or am I doing it wrong and should be creating individual repositories for each project? Or is it something else entirely?

EDIT: I delayed in flagging an answer because it had become clear that there are reasons for both approaches, and even though this question came first, I'd like to point to some other questions that are ultimately asking the same question:

Should I store all projects in one repository or mulitiple?

One SVN Repository or many?

Answer 1

I am surprised no has mentioned that this is discussed in Version Control with Subversion, which is available free online, here.

I read up on the issue awhile back and it really seems like a matter of personal choice, there is a good blog post on the subject here. EDIT: Since the blog appears to be down, (archived version here), here is some of what Mark Phippard had to say on the subject.

These are some of the advantages of the single repository approach.

1. Simplified administration. One set of hooks to deploy. One repository to backup. etc.
2. Branch/tag flexibility. With the code all in one repository it makes it easier to create a branch or tag involving multiple projects.
3. Move code easily. Perhaps you want to take a section of code from one project and use it in another, or turn it into a library for several projects. It is easy to move the code within the same repository and retain the history of the code in the process.

Here are some of the drawbacks to the single repository approach, advantages to the multiple repository approach.

1. Size. It might be easier to deal with many smaller repositories than one large one. For example, if you retire a project you can just archive the repository to media and remove it from the disk and free up the storage. Maybe you need to dump/load a repository for some reason, such as to take advantage of a new Subversion feature. This is easier to do and with less impact if it is a smaller repository. Even if you eventually want to do it to all of your repositories, it will have less impact to do them one at a time, assuming there is not a pressing need to do them all at once.
2. Global revision number. Even though this should not be an issue, some people perceive it to be one and do not like to see the revision number advance on the repository and for inactive projects to have large gaps in their revision history.
3. Access control. While Subversion's authz mechanism allows you to restrict access as needed to parts of the repository, it is still easier to do this at the repository level. If you have a project that only a select few individuals should access, this is easier to do with a single repository for that project.
4. Administrative flexibility. If you have multiple repositories, then it is easier to implement different hook scripts based on the needs of the repository/projects. If you want uniform hook scripts, then a single repository might be better, but if each project wants its own commit email style then it is easier to have those projects in separate repositories

When you really think about, the revision numbers in a multiple project repository are going to get high, but you are not going to run out. Keep in mind that you can view a history on a sub directory and quickly see all the revision numbers that pertain to a project.

Answer 2

The revision number should really only be an identifier for a particular version. Whether it's sequential for a project or not shouldn't matter. That being said, I can understand that it's less than ideal.

Most projects I've encountered have been setup in a single repository and the revision ids behave in this way. I don't know any SVN configuration option to change this behavior, and IMHO, maintaining multiple repositories seems like an unnecessary overhead.

Answer 3

The revision-numbers have no semantic use. The only thing is, that they are in sequential order. If you dump your project and import it in another repository, your versions can get new revision-numbers. So NEVER use the revision-numbers to mark your releases or similar stuff. Make tags for releases (copies of the relevant revision).

Answer 4

One repository per project.

Steven Murawski's comment about CC.NET is an interesting one. I would be interested to hear how it works if you need to specify several source control repositories.

Answer 5

I'm not sure the SVN docs actually recommend one project per repository. Mostly they talk about the upsides and downsides of each path. I happen to use three different repositories, one for 7 or 8 projects that are all related, making it very nice to be able to send out compatible copies of all the projects just by building from one revision (or verifying they're compatible by looking at the revision numbers on each). The second repository has another group of related projects and documents, while the third is a much smaller one. That lets us take advantage of the fact that the related projects can be managed by a single revision number, but that unrelated projects don't affect their repository.