On Mon, 2011-09-12 at 10:41 -0400, Mark Phippard wrote: > On Mon, Sep 12, 2011 at 10:37 AM, Mark Phippard <markp...@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
