Bert and others,
I've been having a think, and this is how I think conflict info should
be logically structured in the WC. It's an attempt to unify tree
conflicts with other conflicts to the extent that it makes sense to do
so, and to provide enough info to fill in the old
svn_wc_conflict_description_t.
APIs for setting and retrieving this info are not specified here. (I
haven't thought of them.)
[[[
This is the information that needs to be stored in the WC to represent
the conflict state of a node.
Conflict state is per node-path. A path is in conflict or not in
conflict. If it is in conflict, it is either in "tree conflict" or in
"content conflict" which means text and/or one or more properties
conflict. When a tree conflict is resolved, or when the text conflict
(if any) and all property conflicts (if any) are resolved, then the path
is no longer in conflict.
A path can be in conflict (tree conflict) even if no BASE node is
present and the node is not even scheduled for addition. The node's
parent dir must exist in the target for this to happen, otherwise a tree
conflict would be raised higher up the tree instead. This happens when a
merge attempts to modify/replace/delete a node that does not exist in
the target. Then a tree conflict exists on the path, reason = missing.
The version of the node in which conflict resolution is performed, is
the (new) ACTUAL version.
When this conflict information has been made available, the BASE will
have already been updated (in an up/sw) and the ACTUAL will have already
been modified (if the up/sw/merge was able to partially complete its
merge), possibly leaving conflict markers in it.
/* The conflict state of a specific path.
* If this info exists on a path, the path is in conflict,
* else the path is not in conflict. */
struct conflict_state
{
/* What kind of conflict?
* At this level, it's just "tree" or "content". */
enum { tree_conflict, content_conflict }
/* Why is there a conflict (in broad, woolly terms)? */
operation
action
reason
/* References to all the relevant versions of the node.
* The implementation needs to be able to retrieve the
* details and content, and may want to store/cache some
* of the details and content. */
src_left_version /* for up/sw, = old BASE */
src_right_version /* for up/sw, = new BASE; aka THEIRS */
tgt_mine_version /* = old ACTUAL */
/* A place for the client to remember which parts of the conflict it
* considers have been resolved. "In conflict" means "not resolved".
* For a tree conflict, these shall be initially all true. */
is_text_in_conflict
is_prop_in_conflict{keyed by prop name}
}
enum operation:
{ merge, update, switch }
enum action:
{ edit, add, del, replace }
enum reason:
/* For up/sw: */
{ edited, added, deleted, replaced }
/* For merge: */
{ different, obstructed, missing, wrong_kind }
/* ### Have a single enum with all eight values? The present
* merge code is a bit muddled about reasons - like "added"
* vs. "obstructed". Need to choose one clear set of reasons. */
src_left_version, src_right_version:
/* Identify a versioned node.
* Must be able to retrieve text or children, and props. */
svn_wc_conflict_version_t
tgt_mine_version:
/* Identify a versioned or unversioned node.
* Must be able to retrieve text or children, and props. */
svn_wc_conflict_version_t
]]]
We need a bit of work on the svn_wc_conflict_version_t to make it
possible to retrieve the text/children/props through it, and to make it
defined for an unversioned node as well as a versioned node.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2401715
Received on 2009-09-29 19:21:00 CEST