This mail is part 2 in a series regarding the conflict information storage (see [1] for part 1).
The current Plan (as denoted in both wc-metadata.sql and the conflict-storage notes) is to store conflict information in the ACTUAL node. This works fine (and is currently being done on trunk), but seems to break an assumed invariant that every node will also have an entry in NODES. The docs in wc-metadata.sql state that "A NODES row must exist if this node exists, but an ACTUAL_NODE row can exist on its own if it is just recording info on a non-present node - a tree conflict or a changelist, for example." So in theory we allow ACTAUL nodes with conflict info without a NODE entry, but not in practice. One of the places this bites us is when retrieving children. Child nodes which are victims of a conflict should be returned as part of the child list APIs (which ultimately call libsvn_wc/wc_db.c:gather_children()). Those APIs currently only look in NODES to find children, without tacking on the conflict victims embedded in ACTUAL.tree_conflict_data. In crafting a patch to do this, I run into various places in wc_db where a NODE is assumed if an ACTUAL node exists. For instance, I'd like to rewrite libsvn_client/commit_util.c:bail_on_tree_conflicted_children() so that it iterates over the children of the directory in question, rather than use the (soon-to-disappear) "give me all the tree conflict children on this node" API. However, if conflict victims aren't returned as part of gather_children(), that API has no way of knowing about those children who exist only as conflict victims. I believe there are other reasons to include conflicted children in the child lists as well. In the end, I'm not really sure what the best solution is, or how to get there. I've thought about the possibility of having a NODE with op_depth=-1 for nodes who only have an ACTUAL node, if only to satisfy the "ACTUAL must have NODE" invariant. Any other comments or thought are welcome. -Hyrum [1] http://svn.haxx.se/dev/archive-2010-10/0392.shtml
