I need a sanity check here if we can, any ideas on correcting/changing the following are very welcome! We’ve been getting ourselves in knots of late with our SVN and are trying to correct it by putting a Trunk/Release system in place.
We have a large website that we develop on and we store it all in SVN. Heres what we had in mind:
- We have trunk and a release branch
- All work gets checked into Trunk.
- When a feature is deemed ready for the next release it is merged into a Release branch.
- We only have one release branch and just tag “Latest” when we do a push to live
- We hope to be able to get all the files changed from Latest to Head to give us a zip that we can upload (any ideas on an easy way to do this via scripting?)
So we set all this up and where very happy with ourselves. Except its not working and heres why.
We work on lots a different features/fixes/problems at once and they don’t all get nicely checked in feature complete (but always working at least). Then sometimes you have to wait for Clients to sign off. As a result you end up with revisions which are “ready for live” being scattered with ones which are “still being worked on” in trunk. That means that the completed revisions are not getting merged in sequentially but out of order. I thought SVN could handle this, clever little thing it is, but apparently not.
Heres an example:
- Pete changes some CSS to make a new button look pretty (Revision 1)
- Dave add some CSS to the bottom of the same CSS file as Pete’s for a new feature (Revision 2)
- Dave’s mod gets the nod so he merges it into Release and commits it with a log message mentioning revision number and bug tracking id.
- Pete adds more buttons to finish this mod, no CSS changes here though (Revision 3)
- Pete then merges his mods (Revision 1 and 3) into the Head of Release (which has Daves merge in it) but this over-writes Daves CSS additions which now dissapear completely.
This leads to the site being broken and the Release branch being pretty much useless.
So we tried some other ideas like reverting Release back to “Latest” and then just merging in all the Revisions 1,2 and 3 in order. This worked fine until we had Revision 4 which was not ready for live and Revision 5 which was. Suddenly we are getting ourselves in knots again with exactly the same problem!
Ok so take three. Revert to Latest, merge in Revision 5, then do any update back to Head. Tree conflicts galore! So thats a no no.
I cracked in the end and built it all up manaually but its not something I want to do regular, ideally I want to script our deployment but can’t while Release is in such a mess.
HELP! What the heck are we doing wrong? I can’t seem to find any solutions to this problem of wanting different none sequential Revisions in Release. If its not possible thats fine but how the heck are we meant to get stuff live easily. We can’t branch for every single change, the site takes 30 minutes+ to check out it would take too long.
Side note, we are using TortoiseSVN so can we keep command line examples to a minimum in any answers?
Latest version of TSVN and SVN Version 1.6 so we have the funky merge tracking etc.
EDIT: An excellent blog post which deals with the dev/release cycle (although using GIT but still relevant) thought everyone would like to read it if they found this question interesting. (http://nvie.com/git-model)
EDIT 2: I wrote a blog post on how to show which branch you are working on in your website which others have asked me about (http://www.offroadcode.com/2010/5/14/which-svn-branch-are-you-working-on.aspx). Hope that helps. In the meantime we are looking at Kiln and hoping to make the switch next month (gulp!)
You are doing several development efforts on one branch, and those efforts should not be done at the same time (because their lifecycle is different, i.e. they won’t be released at the same time)
You should define a branch per development effort (and not per developer), and merge those branches in a pre-release branch (to integrate all the approved developments for release), with a final merge to Release when all developments have been validated together.
If each development is fairly sequential per developer, that mean each developer can keep one workspace per general task, and checkout only the relevant workspace for that set of tasks: the number of files actually changing would be small, reducing drastically the checkout time.
See: