What is a good repository layout for releases and

问题:

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?

回答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

回答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.

回答3:

When we want to prepare for the release of, say, version 3.1, we create a branches/3.1-Release branch, and merge individual commits from trunk as we seem fit (our release-branches usually only receive the most critical fixes from the main development branch).

Typically, this release branch lives through the alpha- and beta- testing phases, and is closed when the next release is on the threshold.

What you can also do, once your DVDs are pressed or your download package uploaded, is to tag the release branch as released, so you can easily rebuild from exactly the same revision if you need to later.

Carl

回答4:

We already use tags, although we have the one-big-project structure rather than the many-small-projects you have outlined.

In this case, we need to tag, e.g. 1.0.0, but also branch, e.g. 1.0. My concern is mixing project branches and release branches together, e.g.

branches
    this-project
    that-project
    the-other-project
    1.0
    1.1
    1.2
tags
    1.0.0
    1.0.1
    1.1.0
    1.2.0
    1.2.1

回答5:

Where I work, we have "temp-branches" and "release-branches" directories instead of just "branches". So in your case project branches would go under temp-branches, and release branches (created at time of release, of course) would go under release-branches.

回答6:

Another important consideration is when to branch and when to close a branch -- which depends on your release schedule but also how long it takes you to test and release. In my experience this takes a lot of management in terms of ensuring everyone in the team knows what the plan is and when to use what, all of which was helped by documeting it all in a release wiki.

Not quite the answer you are looking for but I think once you have the structure sorted, for which you've had plenty of good suggestions already, the next challenge is keeping the team informed and on track.

回答7:

Releases is the same as tags... Have you got multiple projects inside your trunk? In that case, I would copy the same folders inside tags

So

trunk
     fooapp
         stuff...
     barapp
         stuff...
tags
     fooapp
         1.0.0
         1.0.1
     barapp 
         1.0.0