SVN Repository Structure - Why is this better?

Question

I've been told that most development shops have the following structure or at least close to this:

• Main Repository
  • Project folders underneath
  • Each Project folder has a trunk, branches, and tags folder

so:

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
        ...

So why is this better or best? What happens or what heartaches have you come across if you did it another way?

Answer 1

Most people do this because it's recommended by the Subversion book.

Here's a good explanation from the director of the CollabNet Subversion project:

http://blogs.collab.net/subversion/2007/04/subversion_repo/

Answer 2

That's what we have. It works and that's good enough for now (because we never know what the future will bring) We don't have any compelling reasons to spend some valuable time (and money) to find a possibly more optimal structure.

M.

Answer 3

In systems like CVS, you didn't keep separate "directories". You just tagged and branched.

However, SVN is modelled more on the idea of snapshots, and therefore "copies" of stuff are done very efficiently. Rather than tagging or otherwise marking special (or alternate) versions of a project, it's easier (and more efficient) to make a named copy of it.

Answer 4

Ok, I'm going to be a little more preachy and come down firmly on the side of having a trunk,tags & branches for each project.

The main alternative is to have a single trunk,tags & branches with all projects underneath. However, this leads to a number of problems, one of which is significant and I'll detail here:

Primarily it paves the way to the untouchable library, where everyone's scared to touch a particular library because any change may break something subtle in some random project. The cause of this is that because there's no separation between projects, anyone can effectively change the code in your project without you being able to either detect or control it.

What happens is that one day you check out your project and it builds, the next day you check it out and it fails, but you've made no changes to your project. What's happened is that someone has changed a library that you depended on. In a large structure with many dependencies, it's unrealistic for a developer to test their library changes against every project, especially if they have to make breaking changes. What you need in your project is a reference to a specific version of the library. That way, the library only gets updated when you change the reference to the latest version.

This kind of reference has 3 effects: 1 your project is isolated from random intermediate development changes to the library. 2 you get a revision in your project that tells you that "I'm now using this version of the library". 3. You get to control when you make the changes to your project to account for any breaking changes in the library.

There are other issues which I can go through if this isn't enough.