> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Thursday, December 06, 2007 8:51 AM
> To: Subversion Developers
> Subject: Bogus mergeinfo from a 3-way merge?
>
> I think our mergeinfo-less 3-way merge code has a minor bug
> in that it allows normal property handling for svn:mergeinfo
> properties, but I might not be thinking straight this
> morning. Maybe someone can help me out.
>
> Let's take an example:
>
> $ svn merge ^/branches/1@HEAD ^/branches/2@HEAD trunk
>
> Now, if ^/branches/1@HEAD has no mergeinfo, but
> ^/branches/2@HEAD *does*, our typical rules of property
> handling in a merge will have us add ^/branches/2@HEAD's
> svn:mergeinfo property to our target (trunk). Of course,
> unlike our other properties that get merge-added in this way,
> svn:mergeinfo has a particularly potent meaning.
>
> Can we actually claim at this point that trunk has had merged
> into it all the same stuff that ^/branches/2@HEAD has had
> merged into it?
My first reaction was, "of course not!". But then, after some thought,
I started thinking it was ok to add the mergeinfo. But then again, what
if text mods are made to ^/branches/2 that don't effect it's mergeinfo,
but either return it to it's pre-merge state or change it so much that
the mergeinfo on it means very little if carried forward as part of a
3-way merge. Cue my highly contrived example:
# Start with a greek tree
# copy 'A' --> 'A_COPY' r2
# copy 'A' --> 'A_COPY_2' r3
# copy 'A' --> 'A_COPY_3' r4
# text mod to 'A_COPY/D/H/psi r5
#
# There are some other text mods under A in r6,7,8
# but they can be ignored for this example (it's just
# the standard setup provided by merge_tests.py:setup_branch).
>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo :
Properties on 'A_COPY_2':
svn:mergeinfo :
Properties on 'A_COPY_3':
svn:mergeinfo :
# Merge the text change into A_COPY_2 and commit
>svn merge %URL%/A/D/H A_COPY_2\D\H -c5
--- Merging r5 into 'A_COPY_2\D\H':
U A_COPY_2\D\H\psi
>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo :
Properties on 'A_COPY_2':
svn:mergeinfo :
Properties on 'A_COPY_2\D\H':
svn:mergeinfo : /A/D/H:5
Properties on 'A_COPY_3':
svn:mergeinfo :
>svn ci -m ""
Sending A_COPY_2\D\H
Sending A_COPY_2\D\H\psi
Transmitting file data .
Committed revision 9.
# Now some edits are made to the file changed
# by the preceeding merge. This could be anything,
# but let's effectively return psi to it's pre-merge
# state with an OS copy from A_COPY's psi.
# Commit that edit.
>copy A_COPY\D\H\psi A_COPY_2\D\H\psi
Overwrite A_COPY_2\D\H\psi? (Yes/No/All): y
1 file(s) copied.
>svn diff
Index: A_COPY_2/D/H/psi
===================================================================
--- A_COPY_2/D/H/psi (revision 9)
+++ A_COPY_2/D/H/psi (working copy)
@@ -1 +1 @@
-New content
\ No newline at end of file
+This is the file 'psi'.
>svn ci -m ""
Sending A_COPY_2\D\H\psi
Transmitting file data .
Committed revision 10.
# Now we merge perform a three-way merge where the first URL has
# no mergeinfo and the second URL does.
>svn merge %URL%/A_COPY/D/H@HEAD %URL%/A_COPY_2/D/H@HEAD A_COP
Y_3\D\H
--- Merging differences between repository URLs into 'A_COPY_3\D\H':
U A_COPY_3\D\H
# The merge updates the mergeinfo on A_COPY_3/D/H with r5,
# but no text mod occurs to A_COPY_3/D/H/psi.
>svn diff
Property changes on: A_COPY_3\D\H
___________________________________________________________________
Added: svn:mergeinfo
Merged /A/D/H:r5
>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo :
Properties on 'A_COPY_2':
svn:mergeinfo :
Properties on 'A_COPY_2\D\H':
svn:mergeinfo : /A/D/H:5
Properties on 'A_COPY_3':
svn:mergeinfo :
Properties on 'A_COPY_3\D\H':
svn:mergeinfo : /A/D/H:5
It seems in this case that the mergeinfo on A_COPY_3/D/H is quite
misleading and it would be preferrable to not record any mergeinfo in
this case (though I don't see how we would detect this case). But like
I said, maybe this is too contrived to really mean anything.
Paul
> Because the fact that that svn:mergeinfo
> property get added means that we effectively are claiming
> just that. And maybe that's okay -- that is, maybe it is
> true that trunk has that merge history. But I can't seem to
> convince myself of that just yet.
>
> If it is *not* universally true, then I would recommend that
> for mergeinfo-dishonoring merges, our merge callbacks ignore
> all svn:mergeinfo propmods in the merge drive.
>
> --
> C. Michael Pilato <cmpilato@collab.net>
> CollabNet <> www.collab.net <> Distributed
> Development On Demand
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 17:36:08 2007