On Mon, 2008-11-03 at 18:45 +0100, Stephen Butler wrote:
> Hello tree conflict fans,
>
> While hacking on svn resolve, I made a list of tree conflict types
> distinguished by incoming "action" and local "reason", printed below
> as "(action:reason)". For each type, I describe what I think the
> effect of each --accept option should be. Operation-specific parts
> are in square brackets.
Thanks, Steve.
Have you read my thoughts in notes/tree-conflicts/resolution.txt? It's
based on what I thought we should do rather than what Subversion
currently does, so it's not a direct answer. It attempts to show the
reasons for defining each action in a particular way.
> Please have a look and make corrections/comments inline.
OK. First, what do you assume is the starting point for the state of the
"working" files and directories in the WC? ("Whatever state Subversion
trunk_at_34033 leaves it in"? "Not touched by the attempted incoming
change"?) I assume the latter: not touched.
I think we can safely say that mention of "update" means "update or
switch".
I assume that "theirs-full" means "I want my victim to end up like the
final state of the incoming change, otherwise known as the merge-right
source", and "mine-full" means "I want my victim to end up like I had it
before I tried this operation that raised a conflict". Such definitions
are in line with the meanings they have for a text conflict. See also
the section 'Meaning of "Choose Theirs" and "Choose Mine"' in
notes/tree-conflicts/resolution.txt.
I assume "accept=base" means "Like the merge-left source". My reasons:
For an update, the pristine base of the WC before the update is the same
as the merge-left source. The only other option I can think of is the
pristine base of the WC after the update, but that would be identical to
"accept=theirs" and identical to "revert". For a merge, it could mean
"Like the merge-left source" or "Like the pristine base of the WC". The
former is directly related to the merge; the latter (which means the
same as "svn revert") is not one of the four versions involved in the
merge (merge-left source, merge-right source, initial target, final
target).
> Thanks,
> Steve
>
>
> (*:*)
>
> working: Do nothing (aside from removing the item's tree conflict
> status).
>
>
> (edit:delete)
Reason "delete" meaning "object is already schedule-delete", to quote
from svn_wc_conflict_reason_deleted.
> base: Revert the deletion of the victim_at_BASE.
OK.
> mine-full: [Update: Apply incoming chagnes to the victim.] [Merge:
> Do nothing.]
Update: you mean "Revert the scheduled deletion, and then apply incoming
changes"? No, I disagree. "My" state is that the victim is deleted. To
keep "my version", I want the incoming changes ignored, the BASE updated
to the new incoming base, and the schedule left as "delete".
Merge: assuming the victim hasn't already been touched at detection
time, I agree.
> theirs-full: Undo the deletion and update the victim (without
> triggering another tree conflict on the victim).
Update: yes.
Merge: No. What you describe is for the meaningwould result in the
version that last existed on the TARGET plus incoming changes, whereas
"their" version is what previously existed in the SOURCE plus its
incoming changes.
> (edit:missing)
This sounds like an "obstruction": a mismatch between metadata and
what's on disk, produced by a mis-use of "svn add" and "svn delete".
We had an idea that we could handle obstructions like tree conflicts,
because they share some things in common. However, I now think they are
sufficiently different that it would make unnecessary complexity.
Therefore I don't care about (edit:missing). I want it to be caught as
an error before tree conflict detection code gets to look at it.
> base: Restore victim_at_BASE in the working copy. [Update: Finish
> updating the victim. Apply to the victim the reverse the
> incoming changes.]
>
> mine-full: [Update: Apply incoming changes to the victim.] Delete the
> victim. We assume the victim is missing because the user
> wants to get rid of it.
>
> theirs-full: [Update: Update the victim to the target revision.]
> [Merge: Delete the victim. Add-with-history the
> merge-right counterpart of the victim.]
>
>
> (edit:unknown) [occurs during merge only]
>
> base: Do nothing.
No, I want the merge-left source to be put here.
> mine-full: Do nothing.
Yes.
> theirs-full: Add-with-history the merge-right counterpart of the
> victim.
Yes.
I'll let you respond to the above before continuing.
- Julian
> (delete:edit)
>
> base: [Update: Finish deleting the victim. Add-with-history the
> victim_at_BASE without local mods.] [Merge: Revert local mods and
> delete the victim.]
>
> mine-full: [Update: Finish deleting the victim. Add-with-history the
> victim_at_BASE including local mods.] [Merge: Do nothing.]
>
> theirs-full: [Update: Finish deleting the victim. "rm" the
> unversioned victim.] [Merge: Delete the victim.]
>
>
> (delete:delete)
> (delete:missing)
> (delete:unknown) [occurs during merge only]
>
> base: [Update: Add-with-history the victim_at_BASE.] [Merge:
>
> mine-full: [Update: Finish deleting the victim.]
>
> theirs-full: [Update: Finish deleting the victim.]
>
>
> (add:add) [occurs only if victim is locally added with history]
>
> base: Revert the victim and "rm" the unversioned item. Finish adding
> the new item, and then delete it.
>
> mine-full: [Update: Finish updating the victim, resolving any text or
> prop conflicts with '--mine-full'. Ideally, we would also
> delete any subtrees newly added by the operation.] [Merge:
> Do nothing.]
>
> theirs-full: Revert the victim and "rm" the unversioned item.
> [Update: Finish adding the new item.] [Merge:
> Add-with-history the merge-right counterpart of the
> victim.]
>
>
> Note:
>
> We'd like to handle obstructions as tree conflicts, but that looks
> rather tricky. Should we disallow --mine-full for victims that are
> obstructions? Or maybe disallow both --mine-full and --theirs-full.
>
>
> (add:obstructed)
>
> base: Revert the victim if it is versioned. "rm" the unversioned
> victim. [Update: Finish adding the new item, and then delete it.]
>
> mine-full: Error. Ideally, we would revert the obstructing victim,
> move it to a temp location, finish the update, then apply
> a diff from the new item to the obstructing victim (i.e.,
> replace the new item with the victim). But a dir->file or
> file->dir replacement can't be done in a single commit.
>
> theirs-full: Revert the victim and "rm" the unversioned item.
> [Update: Finish adding the new item.] [Merge: Hmm, we'd
> have to re-run the merge(s) for the victim subtree.
> Don't know if that's feasible.]
>
>
> (edit:obstructed)
>
> base: Revert the victim if it is versioned. "rm" the unversioned
> victim. Finish adding the new item, and then delete it.
>
> mine-full: Error. See (add:obstructed). Maybe tell the user that
> storing symlinks in a version control system is rather
> silly.
>
> theirs-full: Revert the victim and "rm" the unversioned item. Finish
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-03 21:52:34 CET