On Mon, 2011-09-12 at 10:41 -0400, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 10:37 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> > I have a working copy of trunk and I do the merge shown as r14 (which
> > is what will be created when I commit this merge). Here is the
> > command I run and the diff output of the mergeinfo:
> >
> > $ svn merge ^/branches/b .
> > --- Merging r10 through r13 into '.':
> > A products/roadmap.html
> > U products/index.html
> > U about/index.html
> > U index.html
> > U news/index.html
> > U .
> > --- Recording mergeinfo for merge of r10 through r13 into '.':
> > G .
> >
> > $ svn diff
> > Index: .
> > ===================================================================
> > --- . (revision 13)
> > +++ . (working copy)
> >
> > Property changes on: .
> > ___________________________________________________________________
> > Modified: svn:mergeinfo
> > Merged /branches/a:r6,8-11
> > Merged /branches/b:r10-13
> >
> >
> > This gives a simple example to talk about. What changes would you
> > propose making to this output?
>
> Our emails cross paths. I think this is the output you propose:
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
>
> Mergeinfo differences
> ===================================================================
> Changes merged to '.':
> Merged /branches/a:r6,8-11
> Merged /branches/b:r10-13
Correct, because that example doesn't have any subtree mergeinfo. My
thread is all about what happens when a subtree svn:mergeinfo prop is
added (or removed, or, now I think about it, modified in the same way as
the parent's svn:mergeinfo prop).
> If this is the entire scope of your proposal,
"This" being eliminating mention of svn:mergeinfo changes that would be
invisible to the merge algorithm.
> then I have no objections.
Cool. Thanks for taking the time to understand exactly what I mean.
> I thought you were proposing that you wanted to show that
> /b was merged and then either now show /a at all or somehow
> distinguish that it came with the changes merged from /b. I would not
> object to doing that either, I just do not know how you could.
- Julian
Received on 2011-09-12 17:08:43 CEST