How to Structure Subversion Repositories

Question

I'm trying to figure out the best way to structure our Subversion Repositories initially.

So is it best practice to create an initial repository then sub repositories for each project underneath?

And which repositories should have a trunk, branch, etc. created?

Also, I hear it's best practice not to create a trunk, branch, and tags folders on the root level repository?

I know when I was on another team, we pulled lets say ProjectA but it did not pull down a trunk, branch folders which was nice but I do not know how this was structured on the server to make that happen like this.

Answer 1

To save yourself future maintenance headaches, unless you have HUGE amounts of code, or envision wanting to completely delete a project with a large amount of code, keep everything in one repository. Then make directories for each project. Then, if you'd like to follow Subversions recommendation, put the "trunk", "branches", and "tags" folders under each project's folder.

Answer 2

if you want to keep several project in the repository I would go for this structure

/project1
    /trunk
    /branches
    /tags
/project2
    /trunk
    /branches
    /tags 
...

If you want to keep only one project this will do:

/trunk
/branches
/tags

Answer 3

Subversion book to the rescue.

Answer 4

Keeping separate repositories allows you to customize backup schedules and storage locations on a per repository basis. Also, if you occasionally have to dig into the repository and perform some maintenance or cleanup actions (say, you want to delete a commit from the repo entirely... rare but possible) keeping separate repositories will allow you to do so with minimum interference to other users and other repos.

That being said - for small projects, these things are typically not a big concern. I give another hearty recommendation to the trunk/branches/tags setup.

Answer 5

I prefer fine-grained, very organized, self contained, structured repositories. There is a diagram illustrating general (ideal) approach of repository maintenance process. For example, my initial structure of repository (every project repository should have) is:

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases