On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> 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
> ]]]
Hi Julian,
Questions and comments below. All examples done with
^/subversion/branches/showing-merge-info_at_1189744.
> I want "svn mergeinfo" to show a high-level summary of the situation.
Will we still be able to produce the old-style output via an option?
> 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.
While we are in this space it's probably worth doing something about
mixed-rev working copies. Right now the 'svn mergeinfo' subcommand on
both trunk and your branch doesn't account for (heck, it doesn't even
*notice*) mixed-rev targets. At a minimum 'svn mergeinfo' should
issue some sort of warning akin to what an actual merge generates,
e.g.:
smi>svn merge ^^/subversion/trunk
svn: E195020: Cannot merge into mixed-revision working copy
[1179544:1189744]; try updating first
A few options we might pursue:
1) Refuse outright to operate on a mixed-rev target, raise an error,
and recommend updating to a uniform revisions
2) Proceed, but warn that the target is mixed-rev and the results of
an actual merge may not be what is expected (i.e. conflicts).
3) Other?
> 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.
smi>svn info
Path: .
Working Copy Root Path: C:\SVN\src-trunk-2
URL: https://svn.apache.org/repos/asf/subversion/branches/showing-merge-info
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1189744
Node Kind: directory
Schedule: normal
Last Changed Author: julianfoad
Last Changed Rev: 1189146
Last Changed Date: 2011-10-26 07:56:31 -0400 (Wed, 26 Oct 2011)
smi>svn mergeinfo
Assuming source branch is copied-from source of target branch.
Branch marker: 'ChangeLog*' (found on both source and target)
Source branch: ^/subversion/trunk (r1189762)
Target branch: ^/subversion/branches/showing-merge-info (working copy)
### It might be helpful to show the revision of the working copy target too.
Revision range that could be merged:
origin-1189762
### So this line just shows "origin-Source_HEAD_Rev"? That's a bit misleading
### since origin-1188748 *has* been merged already. Might be more useful
### if 'origin' were replaced with the youngest revision from the source that
### the target has been fully synced to (+1 of course since you are using the
### 'M-N' range notation rather than 'M:N'):
###
### Revision range that could be merged:
### 1188749-1189762
###
### Or maybe just spell out the actual value of the copied-from source + 1:
###
### Revision range that could be merged:
### 1177607-1189762
###
Revision range(s) recorded as merged:
DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.c[1]:
1067687-1072301
DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c[1]:
1067687-1072301
DBG: mergeinfo.c: 738: filter_mergeinfo(in[59], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753: /subversion/trunk[1]: 1177607-1188748
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.h[1]:
1067687-1072301
DBG: mergeinfo.c: 738: filter_mergeinfo(in[46], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[4], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/include/private/svn_temp_serializer.h[1]:
1067687-1072301
to target path '.':
1177607-1188748 from same relative path
to target path 'subversion/include/private/svn_temp_serializer.h':
1067687-1072301 from same relative path
to target path 'subversion/libsvn_fs_fs/temp_serializer.c':
1067687-1072301 from same relative path
to target path 'subversion/libsvn_fs_fs/temp_serializer.h':
1067687-1072301 from same relative path
to target path 'subversion/libsvn_subr/svn_temp_serializer.c':
1067687-1072301 from same relative path
Merged revisions:
r1067687 -- merge *
r1067696 -- merge *
r1067712 -- merge *
r1067714 -- change (at least on some paths) *
### I know this is work in progress, so maybe you are already aware of this
### but all of these revisions predate the rev in which
### ^/subversion/branches/showing-merge-info was branched from
### ^/subversion/trunk, i.e. 1177607, so they are neither merged nor
### eligible, rather they are part of the common history of the two.
...
Eligible revisions:
r1177693 -- change (at least on some paths) *
r1177700 -- no-op *
r1177702 -- change (at least on some paths) *
r1177732 -- change (at least on some paths) *
### These revs are not correct either. This branch is synced with
trunk through
### r1188748, so all of these revisions *have* been merged. Also, r1177700
### is flagged as a no-op, but like the other three changes was operative and
### was merged to the branch in r1182334.
...
smi>
> 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.
The section on subtrees in
http://wiki.apache.org/subversion/SupportedMergeScenarios is blank. I
assume you still plan to support merge-tracking aware subtree merges
right? The concept of a branch root is only to encourage best
practices and enable new features (i.e. the identification of source
branches below).
>
> 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
A way to what? Looks like you stopped mid-though here. I know the
feeling when it comes to merge :-)
> 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 17:31:59 CEST