Erik Huelsmann <ehuels_at_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
Received on 2010-09-10 17:11:43 CEST