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_at_1188748
^/subversion/branches/showing-merge-info_at_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
Received on 2011-10-27 14:11:57 CEST