I’m curious how others have setup their repositories:
- One repository per project or…
- One project per repository
The Subversion book goes into this a bit - and mentions a few pros and cons of each method but I was curious what people were actually doing.
Right now we are ‘One project per repository’. There were a few reasons for making that decision but now we are re-evaluating and considering moving to a single repository for everything. I’m curious if anyone is currently doing that and having issues? Anyone have an alternate setup?
You May Also Enjoy Reading:
13 Comments
just posted my thoughts on the subject here:
http://www.newviewnetworks.com.....ient/?p=51
Jim, Would you mind briefly explaining the difference? Right now I am using One Project per Repository. But i am haivng a hard time visualizing that one Repo per project would be.
Basically I have:
Project 1
- Trunk
- Branch
- Tag
Project 2
Project 3
vs.
Repo
- Project 1
- Trunk
- Branch
- Tag
- Project 2
- Project 3
@dominick - Good blog post. In our instance - all our projects are for one client.
then in your case, I would stick to one repository unless a certain project was so large in scope that it deserved it’s own repository. In other words, can the current project setup handle it or will it require a completely different project management pipeline. Remember that currently branches can be moved only within a repository. So if you do decide to create a separate repository for a client, you will not be able to move code around and maintain their revisions. So any shared code you use for that project would branch. One other consideration is space, but that’s not so much of a problem these days.
I’ve used both and have liked somethings about both, but I’m now using 1 repo, multiple projects. What I like about my current configuration is the reduced maintenance (1 set of hook scripts, 1 set of perms, etc.). What I don’t like is that, for any given project, the revision numbers are sequential.
I had to research this a while back. I was working for a company that had giant repositories, with a number of projects. It was painful to do an update, and almost impossible to pull logs.
Since SVN is a form of file system it reacts like most do. The larger the file system gets performance starts to degrade. That’s where partitioning saves the day.
There are some out there that can pull it off, like the apache repo, but you know they have dedicated a good amount of resources to the machines serving that repo. So if you want performance and don’t have a beefy infrastructure, then go with a repository for each project.
Keep in mind, that you can always link / embed other repositories with the SVN EXTERNALS property.
You’ll be insane to have all your projects in a single repository. There are many reasons, the two main ones being performance, ability to revert to a revision without affecting other projects. Others could be security, storage space, backup/restore, archiving, etc…
Here’s a link to setting up those EXTERNALS.
http://tomdeman.com/blog/2007/.....ur-Project
It builds a symbolic link in the actual repo, it doesn’t actually copy one repo into another.
When you checkout, it will checkout from all external repos, as well, so you will have files from all the repos locally to work from.
Thanks for the feedback - keep it coming! I hadn’t thought about performance but it is something to consider - we have over 150 ‘projects’ and some of them are quite big.
And yes, I’m familiar with svn:externals
Seconding what others have said… one repository per-project / plug-in / logical separate area. Branching, tagging, merging and restoring get all weird and non-happy if you just put everything in one repository.
We have one SVN per project. (This helps us for a number of reasons, but the version numbers make more sense if they are all related to same project!)
I would be more interested in how people are doing trunk, branch and tag directories.
@John - yes - I’ve been looking at some of the big open source projects. Mozilla and jQuery for example. It’s interesting to see how they setup their structure…