version control - Reverse Merge and svn:mergeinfo -

we using svn manage development pipeline, in merge changes first stage of development environment second-stage branch. have created tools merge revisions first stage second stage.

what want alert users using tool when there prior revisions files affected revisions tool moving in first stage not exist in second stage, in order them review potential logical dependencies (regardless of whether these cause merge-conflict), , determine whether these prior revisions should moved second-stage branch.

however, running problem revisions reverse-merged showing false positives. here's scenario

• alice commits revision 100 file stage 1.
• alice realizes have made huge mistake , reverse-merges r100 create r101 same file.
• bob codes new change r102 same file.
• carl ready test bob's change , wants pull second-stage. alerted revisions 100 , 101 impact same program, , should reviewed logical dependencies.

according svn red book section on mergeinfo:

applying reverse merges target's natural history

earlier in chapter (the section called “undoing changes”) discussed how use svn merge apply “reverse patch” way of rolling changes. if technique used undo change object's personal history (e.g., commit r5 trunk, roll r5 using svn merge . -c -5), this sort of merge doesn't affect recorded mergeinfo.

is there way tell 101 reverse merge of 100 in our scenario, , therefore not present user of our tool? potentially run svn diff, seems lot of overhead - hoping use mergeinfo, seems impossible.

any ideas?

we have following policy, commit message of pure revert (svn merge -c -<rev>) must start "reverted: ". have strict commit message template , commit hooks test (if commit message not conform, commit rejected). of course, takes discipline...

you can remove reverts svn:mergeinfo property (svn pe svn:mergeinfo). still requires work. have tasked build manager this.

thirdly, can couple svn commits ticket system. in our case, tickets must have reached state before may merged. commits ticket logged in ticket system. have scripts collect commits ticket , merges them in bulk. allows task-based way of working.

you should pick fits development process. , write tooling (if necessary) support process. subversion quite flexible , have used handful of scripts manage this. have scripts generate dependency graphs (with graphviz) between tickets/revisions.

i hope gives ideas. sorry not presenting silver bullet.