Comments on: Subversion – One Repo Per Project or One Project Per Repo?

By: Jim

Jim — Fri, 18 Jul 2008 14:39:58 +0000

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

By: John Farrar

John Farrar — Fri, 18 Jul 2008 14:03:52 +0000

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.

By: rob

rob — Fri, 18 Jul 2008 04:55:12 +0000

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.

By: Jim

Jim — Fri, 18 Jul 2008 01:29:58 +0000

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

By: TomdeMan

TomdeMan — Thu, 17 Jul 2008 21:38:59 +0000

Here’s a link to setting up those EXTERNALS.

http://tomdeman.com/blog/2007/9/23/Subversion-Tip-How-to-Add-External-Repos-To-Your-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.

By: Rob Gonda

Rob Gonda — Thu, 17 Jul 2008 20:33:48 +0000

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…

By: TomdeMan

TomdeMan — Thu, 17 Jul 2008 19:56:08 +0000

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.

By: Rob Wilkerson

Rob Wilkerson — Thu, 17 Jul 2008 19:45:13 +0000

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.

By: dominick

dominick — Thu, 17 Jul 2008 19:12:08 +0000

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.

By: Jim

Jim — Thu, 17 Jul 2008 19:06:45 +0000

@dominick – Good blog post. In our instance – all our projects are for one client.