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

Re: Progress of extract and merge non-reflective changes from a reflective rev

From: Tom Widmer <tom.widmer_at_camcog.com>
Date: 2007-12-11 14:23:58 CET

Kamesh Jayachandran wrote:
> Folker Schamel wrote:
>>> No, what I suggest is simply that svn:mergeinfo contains all path@rev
>>> which have been merged into that path directly (but not indirectly).
>>> For example, if you have
>>> trunk@30 has svn:mergeinfo = branch1@1-20
>>> branch1@25 has svn:mergeinfo = branch2@1-7
>>> branch1@30 has svn:mergeinfo = branch2@1-10
>>> and then you merge branch1@26-30 into trunk as r31,
>>> then, according to my proposal, you get simply
>>> trunk@31 has svn:mergeinfo = branch1@1-20,26-30
>>> but NOT (as currently, if I understand it correctly)
>>> trunk@31 has svn:mergeinfo = branch1@1-20,26-30;branch2@8-10
>>> and also NOT (as your interpretation)
>>> trunk@31 has svn:mergeinfo = branch1@26-30
>> (A) trunk@31 has svn:mergeinfo = branch1@1-20,26-30
>> (B) trunk@31 has svn:mergeinfo = branch1@1-20,26-30;branch2@8-10
>> (C) trunk@31 has svn:mergeinfo = branch1@26-30
>> Scheme (A) and (C) are just different representations of the same
>> information, so both would work.
>> I personally just would prefer (A) to (C) for simplicity
>> and being "more natural".
>> While (B) lacks information as discussed.
> (A) will expose the following problem.

In the current implementation, but of course that has to be updated to
cope with any change in the mergeinfo property!

> * Do a change /branches/X - r50
> * Merge r50 from /branches/X to /branches/Y, it sets a mergeinfo on
> /branches/Y as '/branches/X:50'.
> * Merge -r20:51 /branches/Y to /trunk
> As of current implementation it would set the mergeinfo on /trunk to
> be like (B) i.e
> /branches/X:50
> /branches/Y:20-51
> If we change it to (A) as suggested by you, It would set it as
> /branches/Y:20-51
> Now if someone tries to merge r50 from /branches/X to /trunk it would be
> a repeat merge and can give raise to a conflict.

Not if the implementation has access to indirect merge info.

> What I think is we should enhance 'repeat_merge_filtering' logic to
> check *all* the merge sources from 'svn:mergeinfo' and correspondingly
> filter the revisions from the requested merge.

A crucial thing for some of the merge tracking algorithms to work is
that the implementation must be able to distinguish between:

a) direct merge info
b) indirect merge info

Since b) is reconstructible from a), it makes sense for the mergeinfo
property only to contain a) (proposals A and C). Proposal B, the current
state of affairs as I understand it, is a 'dead end' since it doesn't
distinguish between A and C. An alternative, that might make you both
happy since it might avoid the need for SQLite for 1.5, is proposal D,
something like:

(D) trunk@31 has svn:mergeinfo = branch1@1-20D,26-30D;branch2@8-10I

Where D and I are for direct and indirect, respectively.

It's likely that I information in the mergeinfo property will be ignored
in some future version of SVN, once the advanced use cases for for
merging are implemented, since they may need a database to optimize
various lookups, beyond what is in the mergeinfo property.

Tom (a lurker who will be using feature branches and wants them to work!)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 11 16:03:59 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.