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

Re: Bogus mergeinfo from a 3-way merge?

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-06 19:16:11 CET

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...)


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

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.