Storing bugfixes as local changes rather than in SVN branch

Question

We are deploying and upkeeping web-sites to different customers. Normally we wait for newest changes to stabilize, then tag subversion version as release, and install than version to customer. Then we receive support requests, and sometimes are forced to make quick bugfixes between releases. I find it troublesome to upkeep these bugfixes in branches, and wonder why not store them as "local changes" in some "Release X.Y"-folder (on build-machine)? Can this work, or is branching the only way?

Reasons for this change are:

• it seems much easier to use WinMerge-utility for merging newest bugfixes into some "Release X.Y"-folder, than using tortoise-svn's "branch integration". WinMerge offers you much finer control over which changes to merge and which not (on file-basis, not commit-basis).

• when keeping bugfixes as "local changes" you have three-way comparison: in "Check for modifications" you can see all the bugfixes in current release, and with WinMerge you can see all the newest trunk-changes (if compare "Release X.Y" with "trunk"-folder)

• also it seems over-obsessive to keep everything in SVN. IMO SVN should serve the user and not the other way around.

• also branch re-integration never merges only those files that have actually changed. It takes along whole bunch of unnecessary files, which make it difficult to track anything in SVN-log.

Answer 1

After careful thinking, we adopted the following scheme.

• Master branch is always a development branch.

• Once a release is made, a release branch is created for this release specifically. Any hot fixes are made against this branch.

• Fixes made to a release branch are integrated into master if this makes sense. Some fixes change things that are long gone from the dev branch. If a fix is small, you can just copy and paste it to the dev source and use diff to see you're correct; you don't always need a formal merge.

• Absolutely no untracked changes to release code is allowed. Unless you can build it from source control with one command and deploy with another, you're doing it wrong (see Spolsky's checklist).

This was back in the day we used SVN. With git, the principles are the same, but branching and especially merging is so much more painless.

Answer 2

Well any approach if done carefully will work, but I must admit it makes me nervous, this mix mode of using SVN and manually merging is likely to end you up in trouble.

I have two suggestions:

1. Make sure you relook at how to mereg with SVN - it should not be that hard ( and you can make WinMerge your default merge tool with Tortoise SVN ) ( TSVN ->Settings -> External Program -> MergeTools
2. If you want to keep the "fixes" separate and deal with them later, you could always make the change on the site, then create a patch - the apply those later. ( TSVN-> Create Patch )