NODE_DATA / NODES status

[Erik Huelsmann <eh...@gmail.com>]

Today, I finished replacing all NODE_DATA queries (UPDATE/DELETE/INSERT) in
wc_db.c by queries which operate on NODES. From here on, I'll start to write
code to query BASE_NODE+NODES and WORKING_NODE+NODES, verifying that both
tables return the same results.

There are however, a few queries in 'entries.c' which operate directly on
BASE_/WORKING_NODE. These queries will need to be migrated. However, in our
old entries, we don't have the concept of op_depths and op roots. That makes
it a bit hard to migrate the entries file to the exact semantics of the
NODES table. When we fix the WORKING_NODE concept to have an op_depth == 1
during migration, however, conversion of the queries in that file isn't much
of a problem.

Does anybody expect serious issues from all working nodes having the same
op_depth?


The alternative would be to set the op_depth of each working node to the
path component count of its local_relpath (making each node a stand-alone
change).


Now that I write the above, I think it's the sanest to make each working
node its own oproot. That would be roughly as simple to code as the
"everything is 1" assumption.


Better ideas? Comments?


Bye,


Erik.

Re: NODE_DATA / NODES status

[Philip Martin <ph...@wandisco.com>]

Erik Huelsmann <eh...@gmail.com> writes:

> There are however, a few queries in 'entries.c' which operate directly on
> BASE_/WORKING_NODE. These queries will need to be migrated. However, in our
> old entries, we don't have the concept of op_depths and op roots. That makes
> it a bit hard to migrate the entries file to the exact semantics of the
> NODES table. When we fix the WORKING_NODE concept to have an op_depth == 1
> during migration, however, conversion of the queries in that file isn't much
> of a problem.
>
> Does anybody expect serious issues from all working nodes having the same
> op_depth?
>
>
> The alternative would be to set the op_depth of each working node to the
> path component count of its local_relpath (making each node a stand-alone
> change).
>
>
> Now that I write the above, I think it's the sanest to make each working
> node its own oproot. That would be roughly as simple to code as the
> "everything is 1" assumption.
>
>
> Better ideas? Comments?

The code in entries.c that writes to the database is used by upgrade,
and only by upgrade.  So it's got to produce the correct depth when
upgrading a working copy, but it only has to cope with things that can
be represented in pre-1.7 working copies.  When upgrade writes a node
into the database the parent should already be present and correct.

-- 
Philip