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:
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.
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.
Recommended to use separate repository per project. In my Apache conf.d directory I have subversion.conf that contains:
Then whenever I start a new project I just run:
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.)
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.
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
It doesn't matter if it increases by 1 or 50 with each commit as far as I'm concerned.
@grom:
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 ?