Subversion revision number across multiple projects

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

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 2

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 3

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 4

I think it is highly recommended that you create separate repositories for each project. If for nothing else than to avoid the scenario you are talking about.

With version control, especially Subversion, you can easily check out pieces of a repository into another working copy and then commit them back to their respective repositories. That allows you to keep them clearly separate and distinct while giving you a great deal of flexibility. Once you get into SVN a little more (I'm assuming you are new.) you can start using hooks and I might see where that could get difficult with you setup. If permission are important to you, a single repository might prove more difficult than necessary.

Also, if you are concerned that it will take a lot of time to setup each repository look into the SVNParentPath variable for the Apache configuration file. (Again, I'm assuming you are using Apache.)

Answer 5

Recommended to use separate repository per project. In my Apache conf.d directory I have subversion.conf that contains:

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

Then whenever I start a new project I just run:

svnadmin create /var/www/svn/myproject

Answer 6

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 7

If having the revision numbers change based on other projects bothers you, then put the projects in separate repositories. That is the only way to make the revision numbers independent.

To me, the big reason to use different repositories is to provide separate access control for users and/or using different hook scripts.

Answer 8

Hm, where I work we have all our projects in the same repository. I really don't see the benefit of separating them, doesn't that just create a lot of extra work -creating new repositories, granting access to people, etc? I guess separate repositories makes sense if the projects are completely unrelated, and you have, say, external customers that needs to have access to the repo.

Answer 9

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 10

@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.

Answer 11

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.

Answer 12

We just have one repository with everything in it, pretty much exactly like your example.

I can't see anything wrong with this - the only requirement for the revision number is that it is

• Unique
• Atomic
• Bigger than it was at the last checkin

It doesn't matter if it increases by 1 or 50 with each commit as far as I'm concerned.

@grom:

Then whenever I start a new project I just run:

svnadmin create /var/www/svn/myproject

I can see this working fine if you've only got 1 or 2 devs, but what happens if the people who are creating new projects don't have shell access on the SVN server to be able to create directories under /var/www ?

Answer 13

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.

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 14

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 15

Had the same problem in my previous company, They use to have like 50 projects running in one repository and it was a nightmare to work on the same projects because of when doing svn updates others would curse....lol...

One thing I have learned that always works out best, One project One Repo....you will never regret it.