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.
(F)
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.
Cheers,
Folker
---------------------------------------------------------------------
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