tags:

views:

143

answers:

7

Possible Duplicates:
One SVN repository or many?
Should I store all projects in one repository or mulitiple?
Best practice for creating subversion repositories?

Which is the standard? Do you create multiple repositories, one for each project? Or, do you have one repository and the folder structure in the repository defines where a project is located?

+4  A: 

I like having one for each project. You don't have commit pollution. Since SVN maintains a universal commit number per repository, when viewing a log, you'll get commits from other projects.

thedz
I'd answer this question, but it would be the same thing.
Babak Naffas
You don't have to get the log for all of the other projects within a combined repository, that only happens if you mistakenly ask for a log of the repository root. If my repo has /trunk/projA (or /projA/trunk) then doing a log of just that tree will give me a log of just projA's changes.
Adam Batkin
A: 

Multiple repositories. As long as you're using Subversion, then each repository has sequential version numbers, which can be nice. It also makes switching to other systems or addressing server-side scaling much easier.

Jim Puls
A: 

I'd use one repository for all my projects, there's no real downside other than the increasing version number. KDE does it for a stupidly large number of projects and hit a million revisions last week with no major downsides I can see.

Mike McQuaid
A: 

Where I work we have many clients and we have a repository for each client. The main advantage to that is that it keeps each client's code base separate.

We have also discussed moving to a single large repository model because we do have some common code of our own (common utility classes and the like) that would be easier it it was all under one roof (so to speak). Whether we go down that road or not hasn't yet been decided. I suspect from a legal stand point that if a client ever asks us to simply hand everything over it would be a lot less messy if everything is nicely segregated.

Colin Mackay
A: 

I prefer one repository. Depending on the way you will access the repository it can be a big hassle to maintain every repository separately (e.g. when accesing them with HTTP, I'd have to set each one up in the Apache configuration). I only set up different ones for main fields (e.g. splitting it in departments or personal/business use). As others already said the only drawback is the inconsistent version number, which I personally think isn't a big deal because the client will version each project correctly anyway (and when you are in the folder for the project it will only display the commits for that specific project, too).

Daff
+1  A: 

We use many repositories. These days we have upwards of 100, and new ones are appearing all of the time. The biggest issue that we have is that it is difficult to get a changelog across multiple repositories at the same time. So let's say you have library A in one repository, library B in another, and you want to release product C that depends on A and B. In order to find out everything that has changed between the previous release and the current release, you need to do a log (or diff, depending on what you are trying to accomplish) across all 3 separate repositories. Tagging also becomes a little bit more difficult. That said, it's pretty easy to script all of that, as well as any other maintenance tasks that you have.

Adam Batkin
A: 

Normally, you would use multiple repositories.

for simplicity i use one repository with projects in appropriate subfolders. i don't really care about my revision number and i still have the ability to assign different permission to different users on specific projects/folders. i have around 4-5 commits per day, depending on the project...

i think it depends on the size, complexity, importance and number of commits per days of your projects.

you might want to create different repositories for your private projects and projects your working in team on...

hope it helped

Atmocreations