> -----Original Message-----
> From: hyrum_at_hyrumwright.org [mailto:hyrum_at_hyrumwright.org] On Behalf Of
> Hyrum K. Wright
> Sent: dinsdag 26 oktober 2010 23:49
> To: Subversion Development
> Subject: wc-ng: Storing conflict information on the victim: trials and
> pitfalls
>
> 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 current code we have a wc_db api to retrieve 'all conflicted
children' of a node, which can be used for this specific use case.
It's also completely impossible to create a svn_wc_entry_t for a node in
this state, so making it a 'proper node' will require some work in more than
a few places.
> 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.
I would suggest dropping the 'ACTUAL must have NODE' invariant and keeping
the rest of the wc_db api as close to the current state as possible.
Making delete-delete tree conflicts proper nodes, will also make simple
users of svn_wc__db_read_info(), as svn_wc_read_kind() return some node kind
for this node. (How would we handle that?)
I think svn_wc__db_read_info() should just return SVN_ERR_WC_PATH_NOT_FOUND
on these nodes.
(Note that we can fix the delete-delete tree conflicts caused by switching
and updating, by just keeping a not-present NODE. But this doesn't work for
delete-delete tree conflicts introduced by merging, as we can only introduce
these not-present markers in BASE)
Bert
Received on 2010-10-27 11:07:12 CEST