On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Paul Burba wrote:
>> 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?
>
> No, only if you choose to display that information *per path*. But I
> suggested we shouldn't show it per path but instead in its own section
> at the bottom of the diff output. (That's what I meant; sorry if it
> wasn't clear because my example showed only one path.)
Ok, I understand you now. I hadn't meant that we'd show the diff for
every subtree, only that if the *target* of the diff had no explicit
mergeinfo but had a parent with a change, then we'd account for that
in the diff. Which is what you show...
>> 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 .
>>
>> [...] what would you expect a non-recursive diff of that subtree to
>> show:
>>
>> C:\SVN\src-branch-1.6.x>svn diff subversion -N
>
> I'd expect something like this:
>
> [[[
> Mergeinfo differences [### on the whole of the diff target]
> =====================
> Merged to '.':
> Merged /subversion/trunk/subversion:r996383
> ]]]
...here
> And with a recursive diff on that subtree I'd expect:
>
> [[[
> Index: tests\cmdline\resolve_tests.py
> [...]
> Index: svn\conflict-callbacks.c
> [...]
> Mergeinfo differences [### on the whole of the diff target]
> =====================
> Merged to '.':
> Merged /subversion/trunk/subversion:r996383
> ]]]
>
>
> Paul Burba wrote:
>> Do we have reason to believe that users are being "mislead and
>> distracted" by diff's current behavior?
>
> I don't have evidence, I just expect it.
Got it and fair enough (I just like to know of any real-world specific
use cases)
>> I'll admit there is plenty to
>> be tripped up by with merge tracking, but I'm not sure that diff makes
>> the top 10.
>
> Sure, I agree. It's just that it's time now for me to start tackling
> some of this stuff. I'll repeat from my last email: 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.
>
> In fact, I'm having a total re-think of what useful information the
> users really want to see, which probably 'svn mergeinfo' should display.
> High-level stuff like "your last catch-up was with branch B up to
> revision Y", or "you have all the changes from branch B except these:
> C1, C2, ...". I'll write separately about those thoughts.
>
>
>> >> That's where this comes in: I do a simple little merge
>> >> and run "svn diff" to check what's happened in the WC and suddenly it
>> >> says loads of stuff has been "merged", not the simple little merge that
>> >> I expected.
>> >
>> > I do not think I agree with you on this.
>> >
>> > As you say, diff should show what has happened in the WC. I do not
>> > see why it should hide changes.
>
> I'm not suggesting it should hide changes, I'm suggesting it should
> display the changes in a high-level interpretation rather than raw.
>
>> If merge brought in legitimate
>> > changes to the svn:mergeinfo property. diff is supposed to show the
>> > changes, and those are changes.
>
> I said this is a choice, and that if we want to display raw changes to
> the property then that is a valid alternative but then we shouldn't be
> using the terminology "Merged: xxx" to describe the change when "xxx"
> was not in fact merged.
>
> Certainly the trivial way to close this "issue" is just to change the
> wording of the currently displayed messages.
>
>> > If we want a WC to be more specifically aware that is has been
>> > modified by a merge, then maybe we should consider that information in
>> > the output of some of our other commands (status, info) ? Maybe we
>> > need a new command or maybe mergeinfo should grow a new option to show
>> > what revisions were merged into the WC?
>
> Sure -- the 'svn mergeinfo' command is the obvious place for hanging
> functionality along the lines of 'give me some information about what's
> been merged'.
>
>> Or maybe diff should get a new option? --consider-mergeinfo?
>
> ... which would switch between raw and interpreted ways of dislaying
> mergeinfo diffs. Sure.
>
>> Assuming we want a way to provide this info, I prefer the idea of
>> leaving diff as-is and using a new subcommand or option to provide it.
>>
>> > It seems like diff is doing what is should.
>
> Do you acknowledge my point about the wording "Merged: xxx"?
>
> - Julian
>
>
>
Received on 2011-09-12 16:46:38 CEST