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