Code freeze in SVN - Build management

问题:

Is there a better way to implement code freeze in SVN than asking all developers to not check in any new code?
We have CruiseControl running, which automatically deploys the latest build to environment. So if new code comes in, the build that was made available earlier changes to the latest one. I want that the build that is deployed is the one from a particular branch/tag, so that any new code check-ins dont affect the deployed build. Only when i tag/branch next time, the new code should be again deployed. How can we achieve this?

回答1:

Use SVN's built in branching functionality. The following link shows you all the details on how to branch (you can also use tags if you prefer): http://svnbook.red-bean.com/en/1.1/ch04.html

回答2:

The subversion convention for doing what you are talking about is creating a tag. Of course, a tag is no different than a branch in that it is just a copy of a certain development line at a certain revision (typically... there are complex tags). However, the subversion best practice is that tags are created once and are NEVER committed to - they are snapshots only.

So my advice would be to tag your build at the revision you want to freeze at, communicate to all of your developers that no commits are to be made to that tag (if they do not know it already), and build from that tag for your releases. Raise holy hell if someone commits to a tag.

回答3:

If you would rather be forceful, you can disable any commits via the pre-commit hook script. We have a few parked repos at work that we keep for historical reasons, thus no new commits are desired. This is how we have frozen these repos.

#!/bin/sh
exit 1

They can still be accessed and checked out but all new commits will fail. Thus in your case you could have a process that locks down the repo on a schedule for the build process.

回答4:

Of course there's also blocking at the access mechanism - tweaking the authz file for example.

回答5:

Use a stable branch and Subversion >=1.5 (server, repository format and clients).

Make a branch from Trunk and designate it as your stable branch. Forbid your developers from committing to this branch, ideally using the authz file of whatever permissions are available to you.

Have a policy that ensures that any code changes get committed to Trunk before they can be deployed, even if these changes originated in a separate branch.

Have cruise control watch, build and deploy from the designated stable branch instead of trunk.

When it comes time to deploy the new software, use subversion's merge feature to merge into the branch from trunk. Always merge this way, only from trunk, and Merge tracking (version 1.5 and above only) will ensure that you can cherry pick and include just the changes you want from trunk, whilst excluding the things you don't want. It will also allow you to visually check exactly what revisions the current release includes and what is excluded.

Once you have merged and checked the results, committing the code will cause Cruise Control to publish - so publishing only happens at controlled points.

If you need to rollback to a previous version, create a tag from the required revision of your stable branch and temporarily point Cruise Control to that instead of your stable branch, when you've sorted out the problems on the stable branch, then you can deploy from the stable branch again, instead of the tag.

You may want to pro-actively make tags before problems occur, perhaps automatically using CruiseControl so that the tags are already in place if you need to switch around.

Do not do any development on the stable branch beyond fixing up merge conflicts, or merge changes from locations other than trunk - it will become very hard to tell exactly what's deployed.