[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Status of the 'showing-merge-info' branch

From: Paul Burba <ptburba_at_gmail.com>
Date: Thu, 27 Oct 2011 11:31:27 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.