[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Diff shows added svn:mergeinfo prop as lots of new merges

From: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 12 Sep 2011 09:22:41 -0400

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


> 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 15:24:06 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.