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.
Received on 2011-09-12 14:48:29 CEST