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 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.
