On Sat, Jul 10, 2010 at 17:55, Erik Huelsmann <ehu...@gmail.com> wrote: >... > Columns to be placed in NODE_DATA: > > * wc_id > * local_relpath > * oproot_distance > * presence > * kind > * revnum
revnum is a BASE concept, so it does not belong here. WORKING nodes do not have a revision until they are committed. If the node is copied from the repository, then the *source* of that copy needs a revision and path, but that is conceptually different from "revnum" (which identifies the rev of the node itself). > * checksum > * translated_size > * last_mod_time > * changed_rev > * changed_date > * changed_author > * depth > * properties > * dav_cache dav_cache is also a BASE concept, and remains in BASE_NODE. > * symlink_target > * file_external I'm not sure that file_external belongs here. We certainly don't have it in WORKING_NODE. > This means, these columns stay in WORKING_NODE (next to its key, ofcourse): > > * copyfrom_repos_id > * copyfrom_repos_path > * copyfrom_revnum > * moved_here > * moved_to > > These columns can stay in WORKING_NODE, because all children inherit > their values from the oproot. I.e. a subdirectory of a copied > directory inherits the copy/move info, unless it's been copied/moved > itself, in which case it has its own copy information. Right. Also note that we can opportunistically rename the above columns to their wc_db API names: original_*. They would be original_repos_id, original_repos_relpath, original_revision. (we can also rename BASE_NODE.revnum to BASE_NODE.revision) >... > Relevance to 1.7 > ---------------------- > > Why do we need this change now? Why can't it wait until we finished > 1.7, after all, it's just polishing the way we versioned directories > in wc-1, right? > > Not exactly. Currently, mixed-revision working copies are modelled > using an oproot for each subtree with its own revision number. That > means that without this change, effectively we can't represent > mixed-revision working copy trees. So, in order to achieve feature > parity with 1.6, we need to realise this change before 1.7. Right now, we support copying a mixed-revision tree. During the copy, we synthesize new oproots at each point where revision != parent_revision. The real problem comes in with a local-add underneath a copy/move-here. Adds do not have a marker to state "I'm not part of the ancestor operation." We also have problems reverting child operations, such as replacing a child of a copy/move-here. 1.6 is apparently able to revert the replacement, returning the node to a copied child. (maybe; there is *some* revert operation that 1.6 can do that our current schema cannot accomplish; Philip may recall it) So. In order to support that 1.6 revert scenario, and to better support future revert capabilities, the NODE_DATA concept is needed. It also solves the local-add under a copy problem. Cheers, -g
