[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: Julian Foad <julian.foad_at_wandisco.com>
Date: Thu, 27 Oct 2011 17:29:21 +0100

Thanks for the comments, Paul. Responses in line...

Paul Burba wrote:
> Julian Foad wrote:
>> 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?

Yes, certainly; that code is currently absent from the branch for
simplicity but yes; that was discussed previously
<http://svn.haxx.se/dev/archive-2011-10/0048.shtml>.

>> 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.[...]

OK, thanks, I'll think about that.

>> 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.

Yes; I initially didprint the directory's rev, but then, because
that's misleading for mixed-rev, I pulled it out. Probably best to
run the "svnversion" code to find out whether it's mixed-rev, and
print accordingly.

> 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

That info is going to come out in the "what's been merged" section.
What I intend here is ...

> ###  Or maybe just spell out the actual value of the copied-from source + 1:
> ###
> ###     Revision range that could be merged:
> ###       1177607-1189762

... yes, that. It's only missing at the moment because the API I'm
calling doesn't provide it.

> 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.

Yes; I *think* that's because of the strange mergeinfo on all the
temp_serializer files, which I should be filtering it out because it's
outside the relevant range, but I haven't implemented that part of the
filter yet in "svn_client__get_source_target_mergeinfo()". (That's a
poor function name as Stefan or Daniel already pointed out on IRC.)

>  ...
> 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.

Yup. The "no-op" and "change" flags are fake: the flagging code
currently just says "no-op" when (REV % 10 == 0). That's why I didn't
mention this stuff in the email. It would certainly be helpful if I
made it print a warning about this, now that you and potentially
others are looking at this branch and running it. Sorry to spring
that on you!

>> IDENTIFYING BRANCH ROOTS
[...]
> 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).

Yes, correct.

>> 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 :-)

Oops. A way to be able to support less "obvious" branching patterns,
e.g. copy trunk to br-1.0, copy trunk to br-1.1, then decide to use
br-1.1 as if it's a sub-branch of br-1.0. And so on. People do that
sort of thing.

>> suggested it should only select a source automatically when it finds a
>> branch root marker, as that means someone has deliberately enabled the
>> feature.

- Julian
Received on 2011-10-27 18:29:55 CEST

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