[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: Folker Schamel <schamel23_at_spinor.com>
Date: 2007-12-11 23:16:43 CET

Tom Widmer wrote:
> Tom Widmer wrote:
>> 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.
> (E)
> svn:mergeinfo = branch1@1-20,26-30;
> svn:indirectmergeinfo = branch2@8-10
> The point is to keep svn:mergeinfo clean and future proofed - as long as
> it says exactly what the merge performed was (basically what command was
> typed in to do the merge), there shouldn't be a problem.

svn:mergeinfo = branch1@1-20,26-30
svn:fancydeadendoverallmergeinfo = branch1@1-20,26-30;branch2@8-10

While I would still prefer (A) to all these variants if possible,
since indirect mergeinfo should be an implementation detail
not visible to the user.


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