What's the right way to manage a release with SVN?

My last employer had developed an elaborate system which sat on top of SVN to deal with ongoing development: (change management) look at bugs/issues and associate them with commits when making the commit by tagging the bug id number and (release management) tag items in SVN as part of a specific release based on the bug/issue tracking system. This second part had a workflow associated with it to get sign-off from users/management. Then, when it came time to do the release (usually every Thursday evening), they could run a command to checkout all the tagged code and deploy it.

My new firm is much smaller and I'm interested in finding a low-cost/low-maintenance equivalent, even if it just means dealing directly with SVN. In particular, I regularly find commits late-in-the-game breaking our build, and it becomes very difficult to untangle what we can include. (So far as managing SVN is concerned, I tend to prefer the idea of tags over branches because it require less forethought, but I'm happy to be convinced otherwise.)

What do people use to tag commits for a release and to do a subsequent deployment? Are there any good open-source solutions to manage a release cycle that allows you to browse SVN from a web browser and tag issues/commits for a release? The best thing that I have seen so far is Jira, but that looks like a very big tool (is it difficult to configure/maintain?). The Apache Foundation makes good use of Jira for this purpose (see, for instance, the Mahout roadmap).

Going even a step beyond this would be to have this same system also include continuous integration so that our unit tests could be run with each commit and each bug/issue would then also have this information associated.

Note: There are some slightly related questions on stackoverflow, but I don't see anything covering this aspect of the deployment cycle and release management (see release-management-in-svn, manage-your-project-life-cycle, 开发者_如何学JAVAand best-way-to-handle-change-management).

If you're finding build-busting checkins too late in the game to fix them efficiently you should definitely hop on the CI train before you start worrying about the release process. Making developers responsible for the integrity of the build is a much easier process when there are e-mails going out every time someone checks something in that screws the pooch. Make it a game; Whoever breaks the build has to babysit it until the next time it gets broken.

Getting up and running with CruiseControl (I used CC.NET) isn't that hard with subversion (I got us from no build process to speak of to completely automated build and deployment with CC.NET and NAnt in about a month, interleaved with other responsibilities of course).

We also use JIRA and it's hard to go wrong there. You can have JIRA watch the subversion commit messages for things like "Fixed PROJECT-11" and it will automagically close the appropriate JIRA item. You can build your release notes from there.

Have you investigated the Tortoise SVN revision graph? If you tag each release (which as others have pointed out does not involve copying files, either on the server or the workstation), then you can see all the revisions in chronological order, with the tags indicating actual releases. You can diff between releases and/or trunk by hilighting the two revisions you are interested in and selecting diff from the context menu