SVN: How can I move one branch over the top of the other?

Question

Due to some mismanagement of our SVN repository, we ended up making a branch, named Stable, containing a stable build of our code (the branch actually got started from a tag of the last release, rather than the trunk).

Basically trunk has been 'infected' by some changes made by our new programmer, who didn't really know what they were doing.

What I want to achieve is making the stable branch the trunk, discarding all these changes since the branch occurred, however I need to make sure I preserve all the history pre branch.

Does the branch contain all the history prior to the branch occurring? (in which case I think I can just move the branch to become the trunk?)

All tutorials I can find talk about merging .. But I'm nervous about that because if my understanding is correct, if there are changes in trunk that do not happen to conflict, I would end up with these in the stable build.

So the question is what is my best option for this situation?

Thanks in advance for your input!

Answer 1

Yes, the branch contains all of the history prior to the copy... so you can just delete your current trunk, and either copy or rename your branch to trunk and you should be good to go.

From svn log --help:

Each log message is printed just once, even if more than one of the affected paths for that revision were explicitly requested. Logs follow copy history by default. Use --stop-on-copy to disable this behavior, which can be useful for determining branchpoints.

Answer 2

There are a few options:

1. You can move your directories in SVN as if (almost) you are organizing your local directories. All the history would be retained. (which would include your 'move's of course)

2. If you want to bring the repository into a state where this mistake won't be in the history, then you can use the administration features to remove the unwanted change-sets and add them manually to the appropriate place. This might be tedious and you might have to look into your revision numbers if they are referenced elsewhere.

In the mean time I suggest deciding on a strategy with the team so confusions avoided.

Answer 3

I loved the way you described the changes of this programmer. So, if:

• you really really hate this programmer, and want to erase all traces of his doings
• you have admin access to the repository

you could try very carefully to do a svnadmin dump -rX:Y to dump the repo until the infected revision, erase the current repo, and restore it with the not infected one.

Answer 4

In your situation, I would recommend rolling back the changes on your trunk using merge. You can specify the revision numbers in the reverse order to the merge command using the trunk as both the source and destination for the merge. For example, in the working directory for the trunk (note that you may prefer to use the repository urls):

svn merge .@Y .@X .

will roll back the changes made from revision X to revision Y. Also note that the svn merge command has a --dry-run option so that you can verify what will be done before actually making any changes.

Remember that one of the reasons that you use version control is so that you can keep a history of your changes and roll them back if necessary. Even if you don't think so now, the erroneous commits on the trunk are maybe something that you will want to refer to in the future.