How to setup SVN repo for emergency fixes?

Being a developer for a number of years this is something I should know but don't.

I am working on a released product on a small team. I am the main developer committing most of the code but there are a couple other developers that commit from time to time. Currently, we have a staging server running Hudson CI that builds after every commit. Production is updated manually by a simple svn up command when the trunk is stable and tested.

This has generally worked fine except we do have situations requiring emergency/urgent changes to production when code is not finalized in the trunk.

How can I setup the repo to accommodate this situation? I thought this response was a good reply but it is still a little over my head.

I am thinking, when updating production, create a branch at that revision. However, if I need to make urgent production fixes, how do I access that branch and how can I update production by pulling from that branch and not trunk? How do I make sure that any urgent fixes for the production branch are also committed to the trunk?

ie. this is the situation I want to have a better solution for because it has occurred a few times

• Rev 1000 is updated on production
• Rev 1001-1005 are new feature requests/bug fixes that will be included in the next version
• Rev 1006 is an urgent fix that needs to be pushed to production
• Rev 1007-1009 are more feature updates
• Rev 1010 should be the next revision updated to production

Update:

After reading through the branching section of the SVN Book, I am thinking about the following setup.

1. Create branch when ready to push to prod

   svn copy /trunk /branches/production_01 -m 'Production release'

2. On production, do a switch to the production branch

   svn switch /branches/production_01

3. If an urgent fix is needed, developer needs to make changes in branch:

   svn checkout /branches/production_01

   // make changes

   svn merge /trunk # make sure changes get m开发者_开发技巧erged into trunk as well

   svn commit -m 'Urgent fix

4. On production, update to the latest branch

   svn update

Does this process sound like it would work for our setup?

Creating a new branch every time in order to get ready to release to production is necessary in large teams where people still want to check in new features for future releases while you are trying to stabilize for this release. Unless you are supporting more than one production release at a time, that's not really necessary on a small team.

In your situation I would keep one permanent production branch. Whenever you do a normal release, get it stabilized in trunk, merge trunk into production, and test and push from there.

For a hotfix, create a new branch from production¹, make your changes in there, then merge it both into production and trunk. As with your normal release, you test and push from production.

¹ Always branch from the oldest branch you intend to merge back into. It makes the merge much cleaner.

There are different ways of tackling this problem, but I think the most efficient way I have seen this done is the following:

• All devs go into branches, be it bug fixes or new features. These branches are under CI, and are deployed in their own environment for testing.
• Code that is to go into Production is merged into trunk from a branch (either bug fix branch, or feature branch). trunk is also under CI. Once tested approved, it can then move to pre-prod, and then prod. Only code from trunk is released into Production.

So basically any code that goes into trunk is a merge from a branch; that way, trunk only contains code that is to be released, and you don't have to make awkward code rollback or branching from a revision.

The drawback is that you need different CI environments, with different app server domains for each branch, plus trunk and pre-prod.

Indeed there are plenty of ways to achieve this. The method of applying hotfixes depends on the overall process of revision control and project releases. As such, I'll prefix my answer by describing the basic revision control process we employ for all our projects:

1. /trunk contains the main development branch, used for active development except when extensive work takes place such as new major features or refactoring. In this case the developer will make a copy to /branches/foo, then merge back into /trunk when the work is done. Choosing whether to work mainly in /trunk or use branches depends on the number of developers, the complexity of the project, the stage of the project and the speed of development. In any case, it's best to try to keep /trunk as stable as possible.
2. Once a milestone is reached, and the work in /trunk is ready for release to the production site, /trunk is copied to, e.g., /tags/2.5.0 (the version number for this release).
3. This release is first applied to a sandbox site (e.g., test.example.com) using svn switch ^/tags/2.5.0 (note caret (^) notation in URL ;) and shown to the client or QA team for review.
4. If the client or QA team request adjustments, steps 1–3 are repeated and the minor version number is incremented (e.g., to /tags/2.5.1).
5. Once the sandbox site has been tested and approved for release, the same steps used to launch the sandbox site are applied to the production site (i.e., svn switch ^/tags/2.5.1).

So then, in the case we need to apply an urgent hotfix to the production site, we will:

1. Apply the fix directly to the release version at /tags/2.5.1 using a local working copy of /tags/2.5.1 or directly on the sandbox site.
2. If the changes were done in a local working copy we will commit the changes and update (svn up) the sandbox site. Then we repeat the review/approval process.
3. Once approved, just update (svn up) the production site.
4. The changes made to the release version at /tags/2.5.1 are merged back into /trunk.