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? 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