Code Promotion with Subversion

Question

I'm working on migrating our dev team to Subversion and improving our repository structure and processes. We're basically going with the standard trunk/branches/tags setup. I was originally planning on using a release branches strategy (branches/1.0, branches/2.0, etc), but am now leaning toward a code promotion model (test and production branches). It's a little better and more intuitive for how our team works, but releases will be a little less straight-forward: we effectively need the test branch to become the production branch. (The production branch is always available for maintenance releases, but the test branch doesn't need to exist between deployment of one release and test-ready of the next.)

Can anyone who is using code promotion recommend the best way to implement promoting a branch from test to production? I figure these are my options, but don't know if they have major pros/cons:

a. Fully merge test branch into production branch, delete test branch
b. Delete production branch, copy test to production, delete test branch
c. Delete production branch, rename test branch to production

Thanks for any advice!

Answer 1

I always thought of branches as short lived, and all my releases are actually in the tags folder. When fixes are needed to a certain release, the tag is copied to a branch, work is done and a new tag is created. I'm curious to see if anyone has a different / better approach.

Answer 2

Your production branches should stay intact. Name them by their release number. ProductName_Production_{major}.{minor}.{minor}. As you migrate from test to production you create a new production branch with the latest version number. Delete the test branch if you wish but it can be treated the same way.

As part of my build process I usually zip up the current production before deploying the next production so that I can then revert to the last stable release if need be. Just an fyi.

I don't generally use branches in this fashion though. I keep each iteration tagged so that I have them all. I use my environments to promote the code from test, to qa, to performance test, to production. Ziping each package along the way for roll back capabilities.

Answer 3

Actually we don't distinguish between main working branch and testing branch on the code versioning level, but it makes sense to me.

I would actually go for an approach like

• main
• test branch
  • test
• production branch (would use the tag folder for these)
  • production1.0

When the test is finished you copy it over to a new production1.1 folder/branch.

Answer 4

I create a tag from whatever branch or trunk for each release.

• tag/1.0_tc1
• tag/1.0_tc2
• tag/1.0_rc1
• tag/1.0_ga

If rc1 is acceptable you simply tag it again as 1.0_ga

Answer 5

first: option b) and c) are the same in subversion as in subversion renames are in fact copy and delete.

That said you only have two choices:

1. Fully merge test branch into production branch, delete test branch

   This is the clean way in terms of subversion. You can see in you svn log which revisions had merged into production and everybodys workingcopy stays intact.

   But it comes with a price: You have to manually do the merges and resolve potential conflicts(if changes in productionbranch occur).

   However you can usually do this with a small amount of overhead

2. Delete production branch, rename test branch to production

   This is the easy way, because you just do a very small operation which is scriptable.

   Disadvantages:

   You will invalidate all workingcopys which were pointing to testbranch(which has become production!)

   Merge tracking is much more difficult, as you cannot review the old production branch easily. Direct changes in production branch are lost(without notification)!

Also keep in mind that you may do not want all commits in testbranch in production(why did you test, if everything goes fine?). So I would strongly suggest option A