On Dec 6, 2007 8: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.
It is tough to get your head around this.
On the surface it seems like you would have had to have merged the
"net effect" of all of those revisions. I am still not sure it ought
to actually modify the mergeinfo property though. I tend to think we
shouldn't, but I am not really sure why.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 15:35:02 2007