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

RFC: Issue 2883 No-op merge (without skip) should not change mergeinfo

From: Paul Burba <pburba_at_collab.net>
Date: 2007-08-22 22:10:57 CEST

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?

Only the affected subtree and its ancestors with mergeinfo get updated:

>svn st merge_tests-1
   M merge_tests-1\A_COPY
   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,5
  Properties on 'merge_tests-1\A_COPY\D':
    svn:mergeinfo : /A/D:1,3-4

Or only the affected subtree gets updated:

>svn st merge_tests-1
   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

I have a slight preference for the default behavior of trunk today,
because that allows for optimal mergeinfo elision and therefore the
minimal number of paths with mergeinfo (to see why imagine merging -r2:5
from A to A_COPY, all three paths would end up with the same mergeinfo
(1,3-5) so then A_COPY/B and A_COPY/D's mergeinfo would elide, leaving
only A_COPY's).

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 22 22:11:13 2007

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.