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