Reverse Merge and svn:mergeinfo

Question

We are using SVN to manage a development pipeline, in which we merge changes from the first stage of the development environment into a second-stage branch. We have created tools that will merge revisions from the first stage into the second stage.

What we want to do is alert users using this tool when there are prior revisions to the files affected by the revisions the tool is moving in the first stage that do not exist in the second stage, in order for them to review potential logical dependencies (regardless of whether these cause a merge-conflict), and determine whether these prior revisions should also then be moved into the second-stage branch.

However, we are running into a problem where revisions that are reverse-merged are showing up as false positives. Here's the scenario

• Alice commits revision 100 to a file to Stage 1.
• Alice realizes they have made a huge mistake and reverse-merges r100 to create r101 for the same file.
• Bob codes a new change r102 to the same file.
• Carl is ready to test Bob's change and wants to pull it into the second-stage. He is alerted that revisions 100 and 101 impact the same program, and should be reviewed for logical dependencies.

According to the SVN Red Book section on mergeinfo:

Applying reverse merges to a target's natural history

Earlier in this chapter (the section called “Undoing Changes”) we discussed how to use svn merge to apply a “reverse patch” as a way of rolling back changes. If this technique is used to undo a change to an object's personal history (e.g., commit r5 to the trunk, then immediately roll back r5 using svn merge . -c -5), this sort of merge doesn't affect the recorded mergeinfo.

Is there any way to tell that 101 is a reverse merge of 100 in our scenario, and therefore not present it to the user of our tool? We could potentially run an svn diff, but this seems like a lot of overhead - we were hoping to use mergeinfo, but that seems impossible.

Any ideas?

Answer 1

I've given this further thought, and the whole premise seems flawed; our original idea was to discard both the original revision and the subsequent reverse-merge revision from the list of eligible revisions returned by mergeinfo but there is no guarantee that the subsequent revision (in which the reverse merge was done) contains only the reverse merge - it could well contain additional edits/changes to the file, in which case it would absolutely need to be applied to the branch to avoid problems in cherry picking other revisions. Thanks to all for your answers.

Answer 2

We have the following policy, the commit message of a pure revert (svn merge -c -<rev>) must start with "Reverted: ". We have a fairly strict commit message template and the commit hooks test for this (if your commit message does not conform, your commit is rejected). Of course, this takes discipline...

You can always remove reverts from the svn:mergeinfo property (svn pe svn:mergeinfo). But this still requires someone to do extra work. We have tasked a build manager with just this.

Thirdly, you can couple your SVN commits to a ticket system. In our case, tickets must have reached a certain state before they may be merged. All commits for a ticket are logged in the ticket system. We have some scripts that collect all the commits for a ticket and merges them in bulk. This allows a task-based way of working.

You should pick something that fits your development process. And write some tooling (if necessary) to support that process. Subversion is quite flexible and we have used a handful of scripts to manage this. We even have scripts that generate dependency graphs (with graphviz) between tickets/revisions.

I hope this gives some ideas. Sorry for not presenting the silver bullet.