Reverting after a merge, bad idea?

Question

Hi,

I'm a newcomer to subversion. Recently, I've done some development in two different branches, where one of the branches was a branch of the other branch. I've merged down some changes from the first branch down to the trunk. However, when trying to merge down changes from the other branch to trunk, everything went haywire. That is, I've had a lot of conflicts, some of which I resolved (but not commited) and some of which are not. What worse is, a lot of the changes I made to the branch were for some reason not merged into the trunk. Now, my only question is, can I just do a revert on my working copy to return the trunk into its previous state? That is, will I mess something up by doing this? My taught is to start all over again and do it more carefully "by hand".

Thanx!

Answer 1

If you haven't committed yet and make a revert, you'll have the last version from the trunk.

I don't think it's possible to return your working copy to the state after first merge and before the second one.

Answer 2

As long as you always only do a merge into a clean and freshly updated working copy, you can always back out of the merging by reverting all the changes the merge did (plus the ones you did to solve conflicts).
Just be sure to never ever try to merge into a working copy that has uncommitted changes.

In order to minimize merge conflicts, you want to

• do one merge at a time (If for some reason you want to commit several merges at ones, you could create a temporary copy of your merge target, merge several branches into that, merge that back into your merge target, and delete it afterwards.)
• merge changes from the trunk into the branch first, resolving all arising conflicts
• always merge back changes from a branch into the trunk (or another branch, if they were created by copying that) using svn merge --reintegrate
• throw aways branches that you reintegrated from and create them anew instead

Answer 3

Reverting your working copy will reset your local files back to what is in the repository. In other words, it gets rid of any local changes you have made. It will not change the trunk (because trunk is in the repository). Revert is pretty much the same as deleting your working copy, and checking it all out again.

If you merged your branch into a working copy of trunk, did not commit it, and then tried to merge your other branch into the same working copy, it's easy: just revert your working copy. You'll loose everything that's not committed.

If you merged your branch into trunk, committed that, and now you want to undo it, you can revert the changes from that commit (it's still called "reverting", but this is a different operation). For example, if you're using TortoiseSVN:

1. Start with a clean working copy of trunk (no local changes)
2. Use Tortoise to view the log from your working copy
3. Right-click the revision you want to undo (the one where you committed the merge), and choose "Revert changes from this revision".
4. Commit that, and you have effectively undone the merge.

To avoid this problem, you should probably be merging changes from the second branch back to the first branch, and be merging changes from the first branch back to trunk. If that's not they way you wanted to work, you probably should have created the second branch from trunk rather than from the first branch. It's easiest to merge back to where you branched from.

Answer 4

If your working copy is messed up, the easiest way is often to delete it altogether, check out again from scratch, and try again. Reverting does the same in theory, but added files will be left around (which can cause problems with later merges). Also, it's obvious what deleting and checking out again does.

So long as you've not done any commits, the trunk in the repository will be unaffected: merge only modifies files on the client side.

As sbi noted, you should always merge into an unmodified working copy, as otherwise svn tends to get confused.