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

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.

Actually if your building Microsoft code, and you use the svn revision numbers as a part of your version string then you could run out. Microsoft compiler will throw an error if any part of the version string is greater than 65535.... In our case we have a massive repository at revision 68876 and we just hit this wall.

Answer 2

At my workplace, we have two repositories. One with public read access, and one for everything else. I'd use just one for everything, but we need different access rights for public/private projects.

That said, I personally don't see the problem with the revision numbers incrementing on every update. The revision numbers could skip prime and even numbers and still do what its supposed to do. Make it easy to get to a specific revision.

Answer 3

This is due to how subversion works. Each revision is really a snapshot of the repository identified by that revision number. If all your projects share a repository then it is unavoidable. Typically, in my experience, however you would setup separate repositories for completely unrelated projects. So short answer is no you are doing nothing wrong it is a common question surrounding subversion but it makes sense when you think about how it stores repository information.

Answer 4

I store one project per repository, and like a previous commenter on this subversion question, I mark shared projects as external, so that they are only in source control once.

I'm just starting to add a CI build server (CruiseControl.NET), so I'll have to see how that all works out, but if my build scripts are right it should not be a problem.

Other than appearance though, it is really a matter of preference (in my opinion).

Answer 5

Maybe it's best not to necessarily make one repo per "project", but rather one repo per "solution" (to use Visual Studio terms). If you have a bunch of "projects" in different folders but they're related to each other, then put them in the same repo.

Answer 6

@Daniel Fone: The SVN docs recommend one project per repository, so that is definitely the way the creators intended it to go. As you can have one server (apache or svnserve) maintain multiple repositories, I've never run into a problem of too much overhead. With VisualSVN Server, installing an apache server and configuring multiple repositories is a snap.