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

[Tom Widmer <to...@camcog.com>]

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.

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Folker Schamel <sc...@spinor.com>]

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