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