> -----Original Message-----
> From: Mark Phippard [mailto:markphip@gmail.com]
> Sent: Wednesday, August 22, 2007 7:15 PM
> To: Paul Burba
> Cc: dev@subversion.tigris.org
> Subject: Re: RFC: Issue 2883 No-op merge (without skip)
> should not change mergeinfo
>
> On 8/22/07, Paul Burba <pburba@collab.net> wrote:
> > I'd appreciate anyone's thoughts on issue 2883
> > http://subversion.tigris.org/issues/show_bug.cgi?id=2883
> >
> > "If merge does not do anything (there are no changes in
> merge source),
> > the svn:mergeinfo property should not be modified."
> >
> > The expected behavior if only the merge target has
> mergeinfo is clear:
> > if nothing was changed by the merge, then don't update the target's
> > mergeinfo.
> >
> > Also, if the target and some of its children both have
> mergeinfo but
> > again nothing was changed by the merge, don't update the
> target's or
> > the subtrees' mergeinfo. But what if, in this second case, a path
> > within one of the subtrees was modified. Should the merge
> target and
> > the subtree have thier mergeinfo updated, the subtree and it's
> > ancestors with mergeinfo, or only the subtree?
> >
> > e.g.
> >
> > Given a greek tree with the following changes (this is from
> > merge_tests.py:mergeinfo_inheritance):
> >
> > r2 - copy A to A_COPY
> > r3 - text mod to A/D/H/psi
> > r4 - text mod to A/D/G/rho
> > r5 - text mod to A/B/E/beta
> > r6 - text mod to A/D/H/omega
> > r7 - merge r4 from A into A_COPY/D
> > merge r5 from A into A_COPY/B
> > merge r3 from A into A_COPY
> >
> > This gives us the following mergeinfo:
> >
> > >svn pl -vR merge_tests-1
> > Properties on 'merge_tests-1\A_COPY':
> > svn:mergeinfo : /A:1
> > Properties on 'merge_tests-1\A_COPY\B':
> > svn:mergeinfo : /A/B:1,5
> > Properties on 'merge_tests-1\A_COPY\D':
> > svn:mergeinfo : /A/D:1,4
> >
> > Currently trunk behaves this way if we perform a merge that affects
> > only a subtree:
> >
> > >svn merge %URL%/A merge_tests-1\A_COPY -c3
> > --- Merging r3:
> > --- Merging r3:
> > U merge_tests-1\A_COPY\D\H\psi
> > --- Merging r3:
> >
> > As you can see, all the subtrees with mergeinfo get r3 added, even
> > though only the subtree rooted at A_COPY/D was affected.
> >
> > >svn st merge_tests-1
> > M merge_tests-1\A_COPY
> > M merge_tests-1\A_COPY\B
> > M merge_tests-1\A_COPY\D
> > M merge_tests-1\A_COPY\D\H\psi
> >
> > >svn pl -vR merge_tests-1
> > Properties on 'merge_tests-1\A_COPY':
> > svn:mergeinfo : /A:1,3
> > Properties on 'merge_tests-1\A_COPY\B':
> > svn:mergeinfo : /A/B:1,3,5
> > Properties on 'merge_tests-1\A_COPY\D':
> > svn:mergeinfo : /A/D:1,3-4
> >
> > In fixing issue 2883, should we keep the current behavior
> or do one of
> > the following?
>
> We definitely want the current behavior. Perhaps if that
> last merge had been --depth=files then we would not want it,
> but otherwise we do.
> Revision 3 was merged into the entire tree, whether it
> needed to update those parts or not. For auditing reasons if
> nothing else, it needs to be recorded everywhere (in your example).
Hi Mark,
The --depth case is a separate matter, it's issue #2827 in fact.
Anyhow, I agree with you that the current behavior is fine, but you
understand once issue 2883 is addressed, that if -c3 *didn't* affect
anything under the merge target that we will *not* update the mergeinfo
on A_COPY, A_COPY\B, or A_COPY/C, even though "Revision 3 was merged
into the entire tree". I mention this because your argument "For
auditing reasons if nothing else" implies to me you may not agree with
issue 2883 at all. Am I misunderstanding you?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 23 02:30:55 2007