On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad <julian.f...@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 > > >
