SVN - Manage a partial merge of a revision

Question

Hello,

So I have an issue that is causing me a lot of grief in Subverion. I am working in a branch that is supposed to remain active until my feature set is development complete before re-integrating. Unfortunately, something I have completed has now been deemed by the business to be 'mission critical' and they want me to cherry pick that functionality out of the branch and push it into the trunk so it can get picked up by QA.

The problem I have is that I developed the functionality in a separate directory which I created while working on something else entirely. So in order to merge the remaining code that my functionality requires, I first need to pull in the directory creation that I did previously.

Here are the revisions that I need to yank:

Rev 20
  A ./project_foo
  A ./project_foo/not_required_file.txt

Rev 24
 A ./project_foo/required_file.txt

So to get this into the trunk I had to do the following:

svn merge -r20:21 -> this gets me the directory as well as the not_required_file.txt
svn revert project_foo/not_required_file.txt -> get rid of the file I don't want
svn merge -r24:25 -> this gets me the file I require

Which worked and got the stuff into the trunk that I wanted BUT when I was dev complete and ran svn merge --reintegrate, I (obviously) did not get the not_required_file.txt back from Revision 20 and thus ran into tree conflicts on it (from further changes I made later).

So I am looking for some guidance on what to do in these situations.

• Is there a way of merging in only the specific changes I want from a specific revision?
• Is there any way of grabbing the changes I deliberately missed when I re-integrate the entire branch?
• Could I create the directory structure I need in the trunk and then merge over only the file changes?
• Can I create another branch, move the required changes over there, reintegrate that branch and then pull from the trunk to my original branch?

Thanks.

Answer 1

A future answer for next time this happens is that you could use a DVCS (I prefer bzr, but git is more popular), which would let you use your existing workflow (check out of svn, do work, commit), but also give you the flexibility to work on a second set of changes in parallel.

This has other benefits too - I've found the ability to commit small changes and revert the last 30 minutes work invaluable.

However, none of this helps you right now :(

Answer 2

Nice question. :-)

Looks like your branches are a little messed up. You have good ideas how to solve it. If it works? Try it out, sometimes you never know.

I think you don't need to merge rev. 21 before 24 in your example. The missing directory will be created, anyway.

If you can't help yourself with branching/merging, try to do the moving of files manually (Tortoise helps you with this).

In general, avoid partially merging revisions. Commit more often so you can do the cherry picking in a cleaner way.

Answer 3

Is there a way of merging in only the specific changes I want from a specific revision?

If you don't want a full revision, I would copy over what you want manually by creating a patch file and applying it to the other branch and committing. That way, instead of subversion skipping that revision later (when you reintegrate the branch), it tries to merge it and you just deal with an ordinary conflict on what you manually copied, but it also merges over the part you originally wanted to skip.

In the case of a file create/delete/add, it would create it at the time of reintegration and avoid your tree conflict, since that 'partial revision' you want wasn't ever officially merged.

In the case where no file was created/deleted/moved, you avoid the potential of forgetting that you excluded part of your revision when you merged it previously.

Following the above prevents your next one:

Is there any way of grabbing the changes I deliberately missed when I re-integrate the entire branch?

If you don't merge a partial revision, there won't be anything deliberately excluded recorded by subversion and you should just have an ordinary conflict to deal with on the portion already copied over.

In your case you may be able to tell subversion to merge that individual revision again, doing the reverse of what you previously did (resolving conflict on or reverting the part you originally wanted, while keeping the part you originally left out), but I'm not sure how this works once the merge has already been recorded.

Alternatively, if you use TortoiseSVN you should be able to select the revision in the log (on your feature branch), right click the file(s) you care about that were modified as part of that revision, and "show changes as diff", save that, and apply it manually back to trunk (or whichever branch is the target of our reintegrate branch).

Could I create the directory structure I need in the trunk and then merge over only the file changes?

Try it out and see. At worst, you checkout another workspace or manually fix the contents of the file (in the event that it skips it)

Can I create another branch, move the required changes over there, reintegrate that branch and then pull from the trunk to my original branch?

Now you're just making my head hurt :) Fixing it manually sounds like less work to me. I would fix the part you excluded on trunk and then retry reintegrating the branch.

Hopefully some part of this is helpful.

Answer 4

just "svn copy" missing folders from the branch to trunk recursively.

Answer 5

For your current issues, you might look into SVK, which has better merging support than SVN (or did the last time I was using SVN heavily enough to have to do merges): http://svk.bestpractical.com/view/HomePage

I notice that you mentioned the problem of multiple teams with varying levels of technical ability, though, so SVK isn't really the best solution. Actually I prefer git-svn over SVK, as it provides similar benefits (even better merging than SVN or SVK).

Depending on the low end of your range of skill levels, SVK might be close enough to SVN that it could do the trick, but it does add some extra steps to pushing out changes, and I don't know how well it's supported under Windows (or if it is supported under Windows), or if that's a problem in your environment.