Stefan Sperling <stsp_at_elego.de> writes:
> On Thu, Jan 06, 2011 at 11:20:40PM +0000, Philip Martin wrote:
>> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>>
>> > What, exactly, stands in the way of us branching for 1.7 stabilization?
>>
>> Performance, particulary on network disks, is still a concern. If this
>> requires using fewer, bigger transactions then we really want to do that
>> before we branch.
>>
>> The biggest wcng feature that needs work is that revert doesn't really
>> work on tree changes. Some of the recursive reverts go through invalid
>> wcng database states before reaching a valid final state (so an
>> interrupt would be bad), and some of the non-recursive reverts leave the
>> database in an invalid state.
>>
>> A related issue: we are bad at detecting invalid wcng database states.
>> I suppose this could be considered a good thing as it allows the client
>> to muddle through in some cases, but if we produced hard errors then
>> perhaps we would already have fixed the code that produces invalid
>> databases.
One feature I missed:
Update should put in all the base nodes when skipping a tree conflict.
Strictly speaking we could have 1.7 behave like 1.6 but that would be
missing a major benefit of centralised metadata. It's possible that
merge should also be putting in more nodes when skipping.
>>
>> There are areas that would benefit from review:
>>
>> - Actual-only nodes, i.e. certain types of tree conflicts. I hacked
>> read_info to get something working, but the API was never really
>> intended for actual-only nodes.
>> - Granularity of transactions
>> - Use of workqueues
>
> What do you think about the query-per-node performance problems?
> I'm surprised you don't mention them.
My first paragraph, "fewer, bigger transactions" covers that. It needs
more than just review.
>> There are small issues that need work. We could fix these after
>> branching but obviously it's more efficient to do it before branching:
>>
>> - timestamps don't self-repair when no mods are detected
>> - cleanup doesn't fix timestamps
>> - wc-to-wc copy breaks timestamps
>> - revert working not-present
>> - delete a child in a replace needs to reset some database columns
>> - operations like mv/rm on a tree with an actual-only node
>> - upgrade 1.6 wc that contains replaced directory (as produced by merge)
>> - the redirect regression tests fail using serf
>> - XFAILs
>
> Wow, nice list. Can you file issues for these points and describe them in a
> little more detail in those issues? That might give people who aren't already
> waist-deep in wc-ng something to chew on.
Will do.
--
Philip
Received on 2011-01-07 10:33:36 CET