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.)
> 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
]]]
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.
> 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 15:55:33 CEST