8

I embarked on a set of major changes that touch a lot of different areas of the application, have required changes to the database schema, our objects and presentation code. I started at rev.1101 You could consider it a perfect case for creating a Branch to be later merged and integrated back into the Trunk once it was tested and complete.

But I didn't create a new Branch. I kept working on the Trunk instead.

Here is the situation we started with

The Trunk is now at rev.1116 and I'm in the unenviable (?) position that I have to perform some bugfixes on the revision about 15 versions ago which is the current release in production and then release bugfixed "rev.1101+bugfixes" to production without any of the work from revs 1102-1116.

Question: How do I "recover" the Trunk and move all the recent changes to a Branch? Do I create a Branch from what's in the Trunk right now and that becomes /Branches/MajorChangeSet, then revert the Trunk back to rev.1101, treat that as the now-official Trunk and start work on the bugfixes there?

A map of our SVN revisions, branches, etc.

UPDATE: I followed the procedure recommended by ChrisH below (according to the mockup above) and we're now in great shape. We have been continuing to update the "rev. 1102 production" with fixes and minor feature enhancements. These have been painless and easy to merge into the trunk to make sure that these changes also make it into our new development effort. Thanks all!

Branch v. Trunk | Branch/Tag/Trunk? | Branch when?

Community
  • 1
  • 1
Mark A
  • 5,881
  • 5
  • 26
  • 34

4 Answers4

5

I recommend creating a release branch each time you start doing release candidates. Trunk stays live for work on things not going in the release (version .next as we say). The release branch is reserved only for bug fixes and stuff that must go in the release. It is good practice to always commit those to trunk first, then cherry pick merge them over to the release branch. Always try to merge FROM trunk into other branches because that keeps things easier. Reintegrating "feature branches" into trunk is fine, but fixing a bug in a release branch then merging it back into trunk should be avoided.

After a release is in the wild, the release branch is kept around for fixing additional bugs and eventually doing minor point releases. You should still fix the bugs in trunk first (no point shipping them in the .next release) and merging them to each release branch you are still actively maintaining.

The good news is you can start this methodology after the fact. Go back to the revision of trunk your current release was built from and create a release branch from that. TortoiseSVN has a handy menu for creating tags and branches from specific revisions when you right click on the revision in the log viewer.

Once you have your release branch you need to check it out and start merging over the bug fixes you want to release. All of your new work in trunk stays right where it is. If trunk and the release branch have diverged significantly then you might need to just make the fixes directly on the release branch, but try to make them in trunk and merge to the release branch when you can.

One more thing. Each time you ship a release from the release branch you should make a copy to tags with the version label of the release. It can be handy later to figure out what changed between releases or to rebuild an old release if you need to. We go as far as doing a complete build from the tag when we ship the release because we embed the SVN revision number in our product version so that if a customer reports a bug we know exactly what code they are running (since SVN revisions are unique across the repository).

Hope that helps, and good luck.

ChrisH
  • 4,788
  • 26
  • 35
  • 2
    I'm glad it worked out so well for you, and I LOVE the update to the question with the diagrams. It is so much easier to understand the pictures than the wall of text I posted. :) – ChrisH Apr 26 '11 at 02:34
  • 1
    Balsamiq mockups in the houuuuuuuse. – Mark A May 02 '11 at 22:04
  • @MarkA: Thanks! I just wondering how you drawed that diagrams :P Very usefull diagrams! :) – Fil Feb 19 '15 at 13:13
0

One approach is to create a branch for each major release, onto which you can apply bug fixes independently of any work going on in trunk.

To create the branch retrospectively, try:

svn copy http://svn/path/to/trunk@1101 \
         http://svn/path/to/branches/last_monday_release

@1101 is a peg revision - essentially we're saying "figure out what trunk referred to in revision 1101, then copy that to make a branch".

(the SVN book has a scary explanation of peg revisions, if you're feeling brave)

SimonJ
  • 21,076
  • 1
  • 35
  • 50
  • I read the description of peg revisions, thank you for the suggestion. I think that's what I created as the Branch? I used TortoiseSVN's "Show Log" and created a new branch from r1101. It was way easier than expected! – Mark A Apr 26 '11 at 02:27
  • Yup, Tortoise is almost certainly doing this behind the scenes. Glad you got it sorted, and I love the diagrams too! – SimonJ May 02 '11 at 10:55
0

Well, it's a bit of a mess no matter which way you look at it, but you also haven't done anything overtly wrong. You've simply continued developing in your trunk - which is correct - but now you need to go back to a previous revision and add some of the changes then re-release.

The problem seems like you have a series of revisions with both bug fixes and new features and you're just trying to take the bugs since a certain point in time and ignore everything else. It would be a little easier if the bug fixes were in discrete revisions (at least for identification purposes), but often they tend to accompany other changes.

Two options:

  1. Take a branch of the last revision which you released then manually move over your bug fixes.
  2. Take a branch of the last revision which had a bug fix then remove the new features.

Depending on the balance between new features and bug fixes, one of these will likely be easier than the other. Either way, you want to end up with a branch just especially for this release.

Troy Hunt
  • 20,345
  • 13
  • 96
  • 151
0

One way to fix this is to

  • make a working branch from HEAD of trunk
  • delete trunk
  • recreate trunk from the trunk revision prior to your accidental changes

This way you will not see the accidental commits and reversions in log/blame on trunk. But be aware when updating working copies - I'm not sure how well svn update handles deletion and recreation of a repository location.

paperjam
  • 8,321
  • 12
  • 53
  • 79
  • Yikes. I would imagine a lot of log history would be lost during these operations? – Mark A Apr 26 '11 at 02:28
  • @Mark You would not lose any log history. `svn log trunk` would just show an extra copy operation. And you could make your accidental changes into a branch, again, not losing any history. – paperjam Apr 26 '11 at 07:32