On Dec 6, 2007 5:51 AM, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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? 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.
I think semantically, what we want is to actually merge the mergeinfo
nonatomically: ie, for "svn merge U1 U2 WC", we want to diff the U1
and U2 mergeinfo, and add that diff to WC's.
I'm not sure if we actually *should* do this, though.
(Cherry-picking continues to be Hard...)
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 19:16:31 2007