Redoing manual merge with SVN merge

I'm trying to fix an SVN project where the 开发者_如何学编程following happened:

A feature branch was taken from trunk There were regular commits to this branch. When it came time to merge the branch back into trunk, the developer didn't use SVN merge, but WinMerge (!), so we lost all of our history for this. In addition there were a number of small bug fixes that were missed in the manual WinMerge. This happened a few weeks ago and there have been regular commits to trunk since then, so we can't simply revert.

So, I'm trying to go back and redo the merge correctly, but this is proving more complex than I'd thought...

If I try to revert to a point prior to this "BadMerge" and then do a proper merge, I can't re-merge the other changes that have happened after BM.

So, I think I have to use svnadmin dump and load, similarly to this, but I can't work out exactly what I need to do.

1. Dump changes prior to BM (ChangesetX).
2. Dump changes post BM (ChangesetY.
3. Load ChangesetX to what? a new repo?
4. Do proper merge of this
5. Load ChangesetY

Is this possible? Any help would be greatly appreciated.

Thanks

Tom

What you can do is:

1. Throw the SVN book at that developer, preferably in the form of a printout on some heavy kind of paper. (If he manages to survive that, fire him.)

2. There's an option for SVN to go through the modes of a merge and record which revisions have been merged in the file and folder properties, but not actually change any files. (Using SVN babble: Their "property status" is "changed", but their "text status" isn't.)

I haven't used the SVN command line in a while, so I don't know how to do this with it, but TortoiseSVN has this:

Probably not the most elegant way, but doable on the client side:

• svn export HEAD of trunk into directory A
• svn checkout BAD_COMMIT of trunk into directory B
• copy over files from A to B

B now contains all commits after BAD_COMMIT as local changes (you lose differentiation between these commits).

Now:

• svn checkout BAD_COMMIT-1 of trunk into directory C
• do the svn merge of your branch, and starting point of your branch in trunk into working copy C
• copy over C to A

Now you have the correct merge in directory A as local changes to HEAD. Commit A. Trunk now has the correct merge as HEAD.

Finally:

• svn update B to HEAD
• resolve conflicts
• commit B

At this point you have commited a sane merge and all changes after the bad merge. You loose some history, but have less hassle then working with dumps on the server side.

Good luck!

You are not limited to take what your versioning tool think is common base, and recording a merge like sbi suggests is probably a good idea. If all else fails, you can always do the merge manually by checking out the three versions of a file and use KDiff3 directly on those like described in the answer linked above.

If versions X and Y are from the feature branch, and versions A to E are on trunk,

    A----------+
    |          |
    |          |
   \_/        \_/
    B          X
    |          |
    |          |
   \_/        \_/
    C <======= Y   Merge without being recorded by svn as a merge (right?), aka BadMerge
    |
    |
   \_/
    D
    |
    |
   \_/
    E

Then to redo the merge check out versions A, Y and B and merge with kdiff3. That will give you a new C' version which preferably will lack the bugs introduced in C. Then you want the rest of the changes done on trunk, so merge C', C and E. That should give you a new version you can check in as version F.

I do not know svn well enough to give any advice on how you should check in C' and how to handle that, but the steps above should at least give you the end result you want.