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

Problem with merge notifications?

From: Paul Burba <pburba_at_collab.net>
Date: 2007-10-08 20:19:52 CEST

Kamesh and I have been discussing some merge notification minutiae on a
thread following up on r26803.

I see a small problem with the way we currently do merge notifications
which I want to put before a wider audience:

Let's say we have the following WC, just a greek tree with a copy of the
'A' dir at r2 followed by some simple text mods to some of the files
under A in subsequent revisions:

>svn st merge_tests-1 -v
                1 1 jrandom merge_tests-1
                1 1 jrandom merge_tests-1\A
                1 1 jrandom merge_tests-1\A\B
                1 1 jrandom merge_tests-1\A\B\lambda
                1 1 jrandom merge_tests-1\A\B\E
                1 1 jrandom merge_tests-1\A\B\E\alpha
                5 5 jrandom merge_tests-1\A\B\E\beta
                1 1 jrandom merge_tests-1\A\B\F
                1 1 jrandom merge_tests-1\A\mu
                1 1 jrandom merge_tests-1\A\C
                1 1 jrandom merge_tests-1\A\D
                1 1 jrandom merge_tests-1\A\D\gamma
                1 1 jrandom merge_tests-1\A\D\G
                7 7 pburba merge_tests-1\A\D\G\pi
                4 4 jrandom merge_tests-1\A\D\G\rho
                8 8 pburba merge_tests-1\A\D\G\tau
                1 1 jrandom merge_tests-1\A\D\H
                9 9 pburba merge_tests-1\A\D\H\chi
                6 6 jrandom merge_tests-1\A\D\H\omega
                3 3 jrandom merge_tests-1\A\D\H\psi
                2 2 jrandom merge_tests-1\A_COPY
                2 2 jrandom merge_tests-1\A_COPY\B
                2 2 jrandom merge_tests-1\A_COPY\B\lambda
                2 2 jrandom merge_tests-1\A_COPY\B\E
                2 2 jrandom merge_tests-1\A_COPY\B\E\alpha
                2 2 jrandom merge_tests-1\A_COPY\B\E\beta
                2 2 jrandom merge_tests-1\A_COPY\B\F
                2 2 jrandom merge_tests-1\A_COPY\mu
                2 2 jrandom merge_tests-1\A_COPY\C
                2 2 jrandom merge_tests-1\A_COPY\D
                2 2 jrandom merge_tests-1\A_COPY\D\gamma
                2 2 jrandom merge_tests-1\A_COPY\D\G
                2 2 jrandom merge_tests-1\A_COPY\D\G\pi
                2 2 jrandom merge_tests-1\A_COPY\D\G\rho
                2 2 jrandom merge_tests-1\A_COPY\D\G\tau
                2 2 jrandom merge_tests-1\A_COPY\D\H
                2 2 jrandom merge_tests-1\A_COPY\D\H\chi
                2 2 jrandom merge_tests-1\A_COPY\D\H\omega
                2 2 jrandom merge_tests-1\A_COPY\D\H\psi
                1 1 jrandom merge_tests-1\iota

# The only initial mergeinfo is from the copy of 'A'.
>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1

# When merging to a target which has no subtrees
# with differing mergeinfo, the merge notifications
# are straightforward. The only unusual thing is
# that the CL -rX:Y range is exlcusive of the
# start revision X (as it's always been) while the
# notifications 'rA through rB' are inclusive of
# both ranges. This has been discussed to death
# elsewhere and is not why we are here :-P
>svn merge %URL%/A merge_tests-1\A_COPY -r3:8
--- Merging r4 through r8 into 'merge_tests-1\A_COPY':
U merge_tests-1\A_COPY\B\E\beta
U merge_tests-1\A_COPY\D\G\pi
U merge_tests-1\A_COPY\D\G\rho
U merge_tests-1\A_COPY\D\G\tau
U merge_tests-1\A_COPY\D\H\omega

>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1,4-8

# To create a subtree with differing mergeinfo
# we'll reverse merge some of the previously
# applied revision ranges. Again, excepting the
# exclusive end range, the notifications agree with
# the requested -rX:Y range.
>svn merge %URL%/A/D merge_tests-1\A_COPY\D -r5:3
--- Reverse-merging r5 through r4 into 'merge_tests-1\A_COPY\D':
G merge_tests-1\A_COPY\D\G\rho

>svn merge %URL%/A/D merge_tests-1\A_COPY\D -r8:6
--- Reverse-merging r8 through r7 into 'merge_tests-1\A_COPY\D':
G merge_tests-1\A_COPY\D\G\pi
G merge_tests-1\A_COPY\D\G\tau

>svn ci -m "" merge_tests-1
Sending merge_tests-1\A_COPY
Sending merge_tests-1\A_COPY\B\E\beta
Sending merge_tests-1\A_COPY\D
Sending merge_tests-1\A_COPY\D\H\omega
Transmitting file data ..
Committed revision 10.

# Resultant mergeinfo looks good
>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1,4-8
Properties on 'merge_tests-1\A_COPY\D':
  svn:mergeinfo : /A/D:1,6

=== EXAMPLE 1 ==============================================

# Now perform a merge to a target 'A_COPY' with a
# subtree 'A_COPY\D' with differing mergeinfo.
# Now we get two notifications as r3 is applied to
# both the target and the sub-tree and then r4-5
# is applied to the subtree. The notifications
# reflect this. Revision 6 is not mentioned in either
# notification since it is not being applied.
# Ok, everything looks fine so far...
>svn merge -r2:6 %URL%/A merge_tests-1\A_COPY
--- Merging r3 into 'merge_tests-1\A_COPY':
U merge_tests-1\A_COPY\D\H\psi
--- Merging r4 through r5 into 'merge_tests-1\A_COPY':
U merge_tests-1\A_COPY\D\G\rho

>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1,3-8
Properties on 'merge_tests-1\A_COPY\D':
  svn:mergeinfo : /A/D:1,3-6

=== EXAMPLE 2 ==============================================

# ...Now revert the previous merge and try another.
# This time revision 6 *is* mentioned in the
# notification, even though it is *not* being
# applied. Shouldn't the notification instead be
# "--- Merging r7 through r10 into 'merge_tests-1\A_COPY':"?
# ^^
>svn merge -r5:10 %URL%/A merge_tests-1\A_COPY
--- Merging r6 through r10 into 'merge_tests-1\A_COPY':
U merge_tests-1\A_COPY\D\G\pi
U merge_tests-1\A_COPY\D\G\tau
U merge_tests-1\A_COPY\D\H\chi

>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1,4-10
Properties on 'merge_tests-1\A_COPY\D':
  svn:mergeinfo : /A/D:1,6-10

=== EXAMPLE 3 ==============================================

# Another problematic example where again r6 is mentioned:
>svn merge -r2:10 %URL%/A merge_tests-1\A_COPY
--- Merging r3 into 'merge_tests-1\A_COPY':
U merge_tests-1\A_COPY\D\H\psi
--- Merging r4 through r5 into 'merge_tests-1\A_COPY':
U merge_tests-1\A_COPY\D\G\rho
# Should be
# "--- Merging r7 through r10 into 'merge_tests-1\A_COPY':"?
--- Merging r6 through r10 into 'merge_tests-1\A_COPY':
U merge_tests-1\A_COPY\D\G\pi
U merge_tests-1\A_COPY\D\G\tau
U merge_tests-1\A_COPY\D\H\chi

>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1,3-10
  
============================================================

There are other examples, but they all deal with the start revision of
the notification.

Does anyone else think the behavior in example 2 and 3 is incorrect? Or
is this acceptable?

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 8 20:24:13 2007

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