[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-12-06 15:34:50 CET

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.

Mark Phippard
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

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.