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

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

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

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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

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 16

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 17

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.