Re: What stands between us and branching 1.7?

"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.

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

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

-- 
Philip