What do you deploy to clients SVN branches or tags

Question

Not long ago we were using Microsoft VSS as our version control tool, and used to create branch of our code after the end of every release and deploy that to our clients.

Now we have moved to SVN and lately there have been lot of discussion about tags/branches, should we tag/branch our code after development for a particular release?

SVN actually recommends "tags" for such a purpose, but also recommend not to make any changes to that further, so where will we make heinous bug fixes that comes up for this release?

Another thing that is doing round is to create both tag and branch, deploy tag to clients, and incase any bug(s) comes up, fix will be made to branch and then tagged again :-(

What do other people do?

Answer 1

Tags on a release branch.

Answer 2

Yes, you typically create a maintenance branch parallel to trunk, and you tag bug fix releases out of that.

Answer 3

In Subversion they are the same thing - they are implemented the same way and the results are the same (aside from your repo hierarchy). They are just references to a specific revision of the repository. No real copies are made. When you start working on a branch (in the real sense of the word) then you are using a new copy of that resource in a new place.

You can always make a branch out of a tag if/when you need, so there is no reason to make a branch and a tag.

If it helps you to be consistent, then go ahead and do it, but in reality it isn't doing anything until you start checking in/making revisions to a branch.

(the tag/branch are both made with a cp command)

Answer 4

Since the source control concept is still pretty new here, especially SVN, we work off the trunk alone. Works great until we have commits that aren't supposed to go live yet, and the person deploying at the time isn't aware of that.

Once everyone is comfortable with SVN here and I can get at least one other person familiar with merging, I'm going to setup a 'live' branch where all approved commits for production can be merged into.

Tags are nice because you can put names to a development cycle, 'beta', 'alpha', 'release candidate 1', etc. But the most important thing you need is a good branch you can rely on for production use. Tags just make it easier to determine milestones.

Answer 5

1. when you make a release, create a tag for it. E.g., release-1.1.0
2. if you have a bugfix/change for that release, create first a branch from that tag, that's the 'stabilization branch', usually named with an '.x' as the last version number. E.g., stabilization-1.1.x
3. merge the bugfix/change from trunk to the stabilization branch
4. commit the change to the stabilization branch
5. once you feel that enough bugfixes/changes on the stable branch are there to justify a new release, create a tag from the stabilization branch, e.g., release-1.1.1
6. keep working on trunk, merge bugfixes back to the stable branch
7. repeat 3-6

Answer 6

Create a tag on the specific revision of a code line (e.g. trunk) and ALWAYS do releases from your tags. Tags in svn, while not enforced by svn itself, are meant to be snapshots and reference points. Take advantage of that implicit notion and only release a build created from a tag that you, and others, know corresponds to a specific release.

Use branches for committing maintenance patches to a specific release (e.g. create a branch from your tag if you need to patch your release) and follow the same for your patches by by tagging your branch when you release from it also.