What is a good repository layout for releases and projects in Subversion? [closed]

Question

We have the standard Subversion trunk/branches/tags layout. We have several branches for medium- and long-term projects, but none so far for a release. This is approaching fast.

Should we:

1. Mix release branches and project branches together?
2. Create a releases folder? If so, is there a better name than releases?
3. Create a projects folder and move the current branches there? If so, is there a better name than projects? I've seen "sandbox" and "spike" in other repositories.
4. Something else altogether?

Answer 1

I recommend the following layout, for two reasons: - all stuff related to a given project is within the same part of the tree; makes it easier for people to grasp - permissions handling may be easier this way

And by the way: It's a good idea with few repositories, instead of many, because change history normally is better preserved that way (change history is gone if you move files between repositories, unless you take special and somewhat complicated action). In most setups, there should only be two repositories: the main repository, and a sandbox repository for people experimenting with Subversion.

project1
   trunk
   branches
     1.0
     1.1
     joes-experimental-feature-branch
   tags
     1.0.0
     1.0.1
     1.0.2
project2
   trunk
   branches
     1.0
     1.1
   tags
     1.0.0
     1.0.1
     1.0.2

Answer 2

Taking off from what others have said, we have a rather rigid structure of progression from alpha, to beta, to production. The alpha code is whatever the head of the trunk is, and is kept stable for the most part, but not always. When we are ready to release, we create a "release branch" that effectively freezes that code, and only bug fixes are applied to it. (These are ported back into the trunk). Also, tags are periodically made as release candidates, and these are the beta versions. Once the code moves to production, the release branch is kept open for support, security, and bug-fixing, and minor versions are tagged and release off of this.

Once a particular version is no longer supported, we close the branch. This allows us to have a clear distinction of what bugs were fixed for what releases, and then they get moved into the trunk.

Major, long-term, or massive changes that will break the system for long periods of time are also given their own branch, but these are much shorter-lived, and don't have the word "release" in them.