On Mon, Sep 12, 2011 at 8:47 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Hi Paul.
>
> Hmm, it's not quite as simple a matter as I first thought.
>
> On Thu, 2011-09-08, Julian Foad wrote:
>> So in "diff" we have a choice. Do we tell the user the physical
>> difference of a particular mergeinfo property, or do we interpret and
>> display what it means? It appears from the wording "Merged" that we are
>> attempting to display the meaning. If so, we're doing it wrong in the
>> cases where the property is added or removed.
>
> In general, the set of paths whose interpreted mergeinfo (that is, the
> logical meaning of the mergeinfo) has changed is not the same set of
> paths that have a physical change of the svn:mergeinfo property. So if
> we're intending to interpret and display the meaning of the mergeinfo
> (change), we can't do this entirely within the path-by-path framework of
> the standard "diff" mechanism.
I didn't fully appreciate that either. If diff is going to take
inherited mergeinfo into account (which in a nutshell is really what
you are proposing...I think) then *every* child path under an
(inheritable) explicit mergeinfo change should show a diff right?
E.g. We merge a change into the 1.6.x backport branch:
C:\SVN\src-branch-1.6.x>svn merge ^^/subversion/trunk . -c996383
--- Merging r996383 into '.':
U subversion\tests\cmdline\resolve_tests.py
U subversion\svn\conflict-callbacks.c
--- Recording mergeinfo for merge of r996383 into '.':
U .
The 'subversion' subtree has no explicit mergeinfo:
C:\SVN\src-branch-1.6.x>svn pg svn:mergeinfo subversion
But what would you expect a non-recursive diff of that subtree to show:
C:\SVN\src-branch-1.6.x>svn diff subversion -N
?????
Obviously it's inherited mergeinfo has changed, so would we show that?
Paul
> I can envisage something like the following style of output being
> helpful, where we omit details of 'svn:mergeinfo' changes from the main
> part of the diff, and instead describe all the mergeinfo changes at the
> end of the diff:
>
> [[[
> $ svn diff INSTALL
> Index: INSTALL
> ===================================================================
> --- INSTALL (revision 1166027)
> +++ INSTALL (working copy)
> [### text diff here if applicable]
>
> Property changes on: INSTALL
> ___________________________________________________________________
> Added: svn:mergeinfo
> [### but don't show any mergeinfo details here]
>
> Mergeinfo differences
> =====================
> Merged to 'INSTALL':
> Merged /subversion/branches/1.6.x/INSTALL:r1000000
> ]]]
>
>
> I haven't thought quite what the format of the "mergeinfo differences"
> output would be, but in principle if I could implement (cleanly)
> something like that, would that make sense?
>
> The intention I'm trying to convey here is that we describe all the
> mergeinfo changes that are relevant to the diffed tree, in terms of
> their logical effect.
>
> This may sound awkward in low-level terms of how to gather this info
> from properties, some of which may be in parent directories in the WC,
> and some of which may be not in the WC at all but only available in the
> repo. But from a user's point of view, if we can't answer the question
> "what have we just merged?" in an understandable way, that would seem
> ridiculous.
>
> To be clear, this is just one issue that I noticed while thinking about
> what the user really wants to see form "svn mergeinfo", "svn diff", etc.
> It's not the most important, and I'm not at all expecting you to jump in
> and "fix" it if we agree it needs fixing. It's just one piece of the
> puzzle that happened to jump out at me.
>
> - Julian
>
>
>> If, instead, we simply want to show a diff of the mergeinfo property
>> itself rather than trying to interpret what it means, the current
>> behaviour would not be surprising. (Nor would it be particularly
>> useful; the raw change of mergeinfo in a particular prop is the sort of
>> thing the user generally doesn't want to know about, beyond the fact
>> that there is some change that they need to commit.) But then we should
>> not say "Merged" but rather "mergeinfo diff" or something.
>>
>> I think the interpreted output is useful.
>>
>> I share your hesitation about "add merge tracking awareness to diff" but
>> there definitely *is* a benefit in showing the user what's logically
>> changed.
>
>
>
>> > > On Thu, 2011-09-08 at 16:59 +0100, Julian Foad wrote:
>> > >> If Subversion creates subtree mergeinfo on a path that previously didn't
>> > >> have any, then "svn diff" incorrectly shows all the source revs in that
>> > >> mergeinfo as newly "merged".
> [...]
>> > >> The bug is that "svn diff" shows a mergeinfo diff assuming that the
>> > >> previous merginfo was an explicit empty set of mergeinfo, but it wasn't,
>> > >> it was inherited mergeinfo.
>
>
>
Received on 2011-09-12 15:24:06 CEST