[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Stages of tree conflict detection in "update" [was: branch tree-conflicts-notify: merge to trunk?]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 28 Oct 2008 13:29:04 +0000

On Mon, 2008-10-27 at 20:36 +0100, Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
> > Now, stages of detection...

BTW, I was talking only about update/switch, not merge.

> I hadn't thought about sub-items 1c or 1d above. Good catch.
>
> So IIUC we'll print one line of output upon detecting an existing conflict
> (1b, 1c, 1d above), or creating fresh tree conflict (#3 below).
>
> I think we should be completely silent for the rest of a conflicted
> tree (1a), to avoid burying the user in lots of "Skipped" messages.

I agree: one notification per conflicted sub-tree. Revised text:

[[[
 * 1. if # Incoming change inside an item already in conflict:
 * a.
 * tree/text/prop change to node beneath tree-conflicted dir
 * then # Skip all changes in this conflicted subtree [2]:
 * do not update the Base nor the Working
 * notify "skipped because already in conflict" just once
 * for the whole conflicted subtree
 *
 * if # Incoming change affects an item already in conflict:
 * b.
 * tree/text/prop change to tree-conflicted dir/file, or
 * e.
 * tree change to a dir tree containing any conflicts, or
 * c.
 * tree change to a text/prop-conflicted file/dir, or
 * d.
 * text/prop change to a text/prop-conflicted file/dir[1],
 * then # Skip this change [2]:
 * do not update the Base nor the Working
 * notify "skipped because already in conflict"
 *
]]]

I've also added a condition "e." which was missing.

> Too much output would distract the user from the initial message,
> which describes where the tree conflict is. After resolving the tree
> conflict, the user can check status or resume update/switch, and find
> any other conflicts in the tree.

Yes.

> > *
> > * 2. if # Incoming change affects an item that's "obstructed":
> > * on-disk node kind doesn't match recorded Working node kind,
> > * including an absence/presence mis-match
> > * then # Skip this change [2]:
> > * do not update the Base nor the Working
> > * notify "skipped because obstructed"
> > *
> > * 3. if # Incoming change raises a tree conflict:
> > * tree/text/prop change to node beneath tree-scheduled[3] dir

Like in (1.), here we insert:

    * then # Skip all changes in conflicted subtree
    * do not update the Base nor the Working
    * notify "skipped because already in conflict" just once
    * for the whole conflicted subtree
    *
    * if

> > * tree/text/prop change to tree-scheduled[3] dir/file, or
> > * text/prop change to tree-scheduled dir/file,
> > * then # Skip this change:
> > * do not update the Base nor the Working [4]
> > * notify "tree conflict"
> > *
> > * 4. Apply the change:

[...]
> Here's my basic implementation plan:
>
> The following update callbacks need to check for existing conflicts:
>
> open_directory
> open_file
> add_directory
> add_file
> delete_entry
> absent_file
> absent_directory
>
> In each callback, we'll make the following checks/calls.
>

1.a.
> (eb->inside_a_tree_conflict)
>
> True if we're walking a tree-conflicted tree. Works even if the
> target and its parent dir do not exist (e.g., we've skipped adding
> the parent dir due to the tree conflict). Skip target silently if
> true.
>
1.b/c/d
> svn_wc_conflicted_p2()
>
> Check for existing conflicts. Requires a versioned parent dir for
> a tree conflict. Requires a versioned parent dir and versioned
> target for text or prop conflicts. Skip target with notification
> if conflicts are found.

1.e. may need a new check.

2. - obstructions - has a fair amount of existing code but should be
rationalized.

3.
> check_tree_conflict(&tree_conflict, eb, ...)
>
> Returns a fresh tree conflict if the target is a victim. Requires
> a versioned parent dir. If a conflict is found, record it
> persistently.
>
> notify_tree_conflict(tree_conflict, eb, ...)
>
> If there's a tree conflict and an eb->notify_func, notify the user.

This should differ:

  for a newly raised tree conflict, notify "tree conflict"

  for a pre-existing conflict, notify "skipped (because of a conflict)"

But any notification is better than none, to start with.

Thanks.
- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-28 15:41:43 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.