Stefan Sperling <s...@elego.de> writes: > On Thu, Jan 06, 2011 at 11:20:40PM +0000, Philip Martin wrote: >> "C. Michael Pilato" <cmpil...@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
