On Tue, 2009-09-29, Julian Foad wrote:
> 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.)
Greg mentioned it should also provide for changes made by "svn patch".
Here's an update.
[[[
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 the incoming change and the local version that it
* conflicts with. We do not mandate here whether the WC stores a
* copy of any or all such changes or nodes, or just metadata about
* them. The API should be able to retrieve the details and content
* of all relevant nodes when possible. */
incoming_change
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, patch }
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. */
incoming_change:
patch_data /* iff operation = patch */
or
src_left_version /* for up/sw, = old BASE */
src_right_version /* for up/sw, = new BASE; aka THEIRS */
patch_data:
/* A reference to, or more likely a copy of, the patch applied to
* this node. A patch may contain some src_left/right metadata. */
src_left_version, src_right_version:
/* Identify a node-rev in a repository.
* API must be able to retrieve the node's content (text or children,
* and props) from this info. */
svn_wc_conflict_version_t
tgt_mine_version:
/* Identify a node of which we definitely can have the full content.
* The node might be a node-rev in a repository (if merging into a
* clean WC), in which case record a reference to this node-rev.
* 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=2401826
Received on 2009-09-30 02:20:25 CEST