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
Received on Tue Dec 11 19:04:51 2007