thecrumb.com

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.

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.

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.