Erik Huelsmann <ehu...@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
