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

[proposal] Handling cascading effect on indirect merge info on a reverse merge

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2006-07-12 15:12:17 CEST


    (Apologize for the loong subject line)

    I encountered this problem while trying to figure out eliding for a
problem mentioned by dlr on irc. Thought could share my thoughts with you
all for your views.


     Assuming the following structure:

     With /trunk changes getting merged into /branches/branch1, and
/branches/branch1 changes getting merged into /branches/branch2.

     If a revision X (say), was a result of a merge of revisions Y-Z from
/trunk into /branches1. Say, we merge X into /branches/branch2. The
mergeinfo for /branches/branch2 would contain:

     /branches/branch1: X
     /trunk: Y-Z

Now, reverting X from /branches/branch2, would effectively mean a revert
of the changes /trunk: Y-Z from the /branches/merge2 mergeinfo. But with
the current mergeinfo format, we can't deduce that /branches/branch1:Z ==
/trunk: Y-Z.

    I have tried to explain this with an example below. (Pl. forgive the
unrelated conflict - and dont forget to read the proposal at the end.)


madan@localhost /tmp/wc/branches/branch1 $ /home/madan/bin/mt/bin/svn
merge ../../trunk -r17:19
U file.c
C file.h
madan@localhost /tmp/wc/branches/branch1 $ vi file.h
madan@localhost /tmp/wc/branches/branch1 $ svn resolved file.h
Resolved conflicted state of 'file.h'
madan@localhost /tmp/wc/branches/branch1 $ svn ci -m "merged r 17:19 from
trunk into branch1"
Sending branch1
Sending branch1/file.c
Sending branch1/file.h
Transmitting file data ..
Committed revision 20.
madan@localhost /tmp/wc/branches/branch1 $ cd ../branch2

madan@localhost /tmp/wc/branches/branch2
$ /home/madan/bin/mt/bin/svnversion ../branch1
madan@localhost /tmp/wc/branches/branch2 $ /home/madan/bin/mt/bin/svn pg
svn:mergeinfo ../branch1
madan@localhost /tmp/wc/branches/branch2 $ /home/madan/bin/mt/bin/svn
merge -r 19:20 ../branch1
U file.c
U file.h
  U .
madan@localhost /tmp/wc/branches/branch2 $ svn diff

Property changes on: .
Name: svn:mergeinfo
    - /trunk:3-4,6,9-11,14-15
    + /branches/branch1:20

Index: file.c
<changes to file.c>
Index: file.h
<changes to file.h>

So far so good.

The problem:

Now, if I do a 'svn merge -r 20:19 ../branch1/file.c' (note only file.c),
we expect to see the following for svn:mergeinfo for file.c:
Property changes on: file.c
Name: svn:mergeinfo
    - /trunk:3-4,6,9-11,14-15
    + /trunk:3-4,6,9-11,14-15,18-19

    (note the removal of the /branches/branch1 mergeinfo)

     Heres my point: I think it should be
Property changes on: file.c
Name: svn:mergeinfo
    - /trunk:3-4,6,9-11,14-15
    + /branches/branch1:17

    (please note the absence of the revision range 18-19 for /trunk in
addition to the removal of the mergeinfo for /branches/branch1)

     I say this because:
/branches/branch1:20 is equivalent to /trunk:18-19


      Now how do we represent this info in mergeinfo so that we could
remove indirect mergeranges when we revert a particular revision. This is
possible if we have a mergeinfo representation like:
    /trunk: 18-19=20

    If we had this information, anytime we revert a particular revision, we
could check for the rangelists with an '=' and see if the current revision
matches/is-a-superset-of the RHS of the '='. If so, we could confidently
remove the whole rangelist entry.

Probable flaw in this proposal:

    If r20 is not just a merge of /trunk: 18-19, but also has some local
diffs. Should we care? Shouldn't we care? I don't know. My head is too
heavy to think anymore.... HELP!

     What do you all think? Pl. let me know if you need more info.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 14:42:11 2006

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.