On Tue, Nov 9, 2010 at 4:50 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Nov 09, 2010 at 09:40:31AM +0000, Philip Martin wrote:
>> Stefan Sperling <stsp_at_elego.de> writes:
>>
>> > Is the op-depth stuff ready for release?
>> > The only other big ticket item to be tackled is the conflict store, right?
>>
>> Currently op-depth is using just two depths, 0 and 2, for base and
>> working. There is code protected by SVN_WC__OP_DEPTH that enables the
>> full op-depth but it's not yet complete. Both sets of op-depth code
>> have known problems. However without SVN_WC__OP_DEPTH it is impossible
>> to support the 1.6 revert-base feature (copy a directory, delete a child
>> of the copy, replace the child, revert the child). Enabling
>> SVN_WC__OP_DEPTH will involve a wc format bump even if it doesn't change
>> the database schema, so if it's not done before 1.7 then it can't happen
>> until 1.8.
>>
>> The other big problem is that the single-db code doesn't really handle
>> tree conflicts properly, it still has the 1.6 behaviour of skipping when
>> a tree conflict is encountered. This means that the base node tree is
>> incomplete which is one of the things that single-db was supposed to
>> fix. Tha fact that the base node tree is incomplete makes it very
>> difficult to understanding the behaviour of the code.
>
> Thanks for the info. Are the items in the issue tracker corresponding
> to the above two points?
>
> I don't think we should risk releasing without complete 1.6->1.7 feature
> parity. So I'd like to see both of these issues fixed before we release.
We've already may some simplifying changes to 1.6 behavior (see recent
changes to encourage non-mixed-revision working copys as merge
targets).
I do agree that 1.6->1.7 feature parity should remain, but we may need
to decide what are features, and what are simply behaviors that
reflected the old implementation. And we need to be up front with end
users about that determination.
-Hyrum
Received on 2010-11-09 14:48:16 CET