At the moment, on the 'showing-merge-info' branch, I have several things going on; here are some of them.
SHOWING SUMMARIZED MERGEINFO [[[ $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x [...] Revision range(s) recorded as merged: to target path '.': 875965,875968,...,1151036 (477 ranges) from same relative path to target path 'CHANGES': 875962-1130989 from same relative path to target path 'get-deps.sh': 878590,878607,...,1126007 (7 ranges) from same relative path to target path 'subversion/include/private/svn_repos_private.h': 878590,878607,...,1126007 (17 ranges) from same relative path to target path 'subversion/libsvn_fs_fs/rep-cache.c': 875965,875968,...,1126007 (456 ranges) from same relative path to target path 'subversion/tests/cmdline/merge_tests.py': 875965,875968,...,1126007 (432 ranges) from same relative path 953878,1146121 from source path 'subversion/tests/cmdline/merge_reintegrate_tests.py' to target path 'subversion/tests/cmdline/svntest/main.py': 991972 from source path 'subversion/tests/cmdline/svntest/sandbox.py' 875965,875968,...,1126007 (441 ranges) from same relative path ]]] I want "svn mergeinfo" to show a high-level summary of the situation. This currently shows the parts of the mergeinfo on the target that pertain to the source branch, including subtrees, in a summarized form. It could be summarized better; for instance, group together several target paths that all have the same source ranges merged to them. After that it currently goes on to print the "merged" and then the "eligible" revisions as lists of individual "operative" (non-empty) changes, with a (currently fake) classification of each change as a "merge" or an "original commit". That's more because I'm interested in the ability to do such classification, and not that I would necessarily want to show that in the "mergeinfo" command output. IDENTIFYING BRANCH ROOTS [[[ $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x Branch marker: 'subversion-source-tree' (found on both source and target) [...] $ svn mergeinfo ^/subversion/trunk ^/subversion/branches svn: E195016: Source branch marker is 'subversion-source-tree' but target has no branch marker $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk svn: E195016: Source and target are the same branch ]]] This looks for a branch root marker property on the specified directory. The property name would be 'svn:branch-root' and the value would be a string that (more or less uniquely) identifies the 'project' (for want of a better word) of which this is a branch. Currently, just for testing, the property it looks for is the first ten characters of 'svn:ignore', which tends to work moderately well for ad-hoc testing against our own source tree because it exists and starts with 'ChangeLog*' in the root of every branch and (I guess) nowhere else. IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY [[[ $ svn mergeinfo Assuming source branch is copied-from source of target branch. ### target is implicit '.' [...] Source branch: ^/subversion/trunk (r1189704) Target branch: ^/subversion/branches/showing-merge-info (working copy) [...] ]]] At the moment this only looks for the copied-from branch, which is not good enough; if we do this at all then we need a way to . Stefan also suggested it should only select a source automatically when it finds a branch root marker, as that means someone has deliberately enabled the feature. MAKING MERGE EXPLAIN WHAT IT'S DOING [[[ $ svn merge ^/subversion/trunk Sync merge from '^/subversion/trunk' into '.' (a working copy of '^/subversion/branches/showing-merge-info') [... and maybe a summary of the revision ranges it's looking to pull in ...] $ svn merge --reintegrate ^/subversion/branches/showing-merge-info Reintegrate merge from '^/subversion/branches/showing-merge-info' into '.' (a working copy of '^/subversion/branches/trunk') The reintegrate merge will be equivalent to: merge ^/subversion/trunk@1188748 ^/subversion/branches/showing-merge-info@1189710 . [...] ]]] I've only just started with this and haven't checked all of this in. We say that 'reintegrate' does a two-URL merge, but in wanting to make it print what it's about to do I notice that the implementation doesn't seem to call the two-URL merge code at all. I want to change that and have the two phases completely separated: first the client should figure out what merge it will do, and print that, then call the two-URL merge code to actually do it. Comments appreciated. - Julian