Quoting Julian Foad <julianfoad_at_btopenworld.com>:
> 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.
Yes, sorry I forgot to mention your doc up front. It's required reading
for this topic. It includes issues that I gloss over, such as the
likely meaning of each situation from the user's point of view.
>
>> 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.
Yes, I assume we'll go back to the general plan of skipping all tree
conflict victims. My quick hack of allowing deletions to continue
ought to be rolled back as soon as we tweak svn add and svn remove
to "do the right thing" to a tree conflict victim, allowing the
user to recover from the skipped deletion.
>
> I think we can safely say that mention of "update" means "update or
> switch".
Yes, and checkout, too. ;-)
>
> 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).
I had assumed that "base" always meant the WC BASE before the operation.
But I suppose 'svn resolve --accept base' is more useful for merge if
it does something different than 'svn revert' does.
>
>> 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".
Yes, I agree we should apply the incoming changes to the victim's
hidden BASE only.
>
> 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.
I think I understand now. This is use case #5 in issue 2282, where
the tree conflict is created because the SOURCE-LEFT differs from
the TARGET. If the user chooses theirs-full, SOURCE-LEFT should be
the starting point.
>
>> (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.
Update throws an error for an obstruction, as it has in 1.5 and
earlier, which has the effect of blocking commit. But merge has
to raise a tree conflict. The pre-1.6 merge behavior is to notify
the user of the obstruction without blocking commit. I believe
we're against that. ;-)
Recovering gracefully from obstructions is difficult and probably
can't be automated, as is obvious from the radical steps that would
be needed for the (*:obstructed) items at the end of this list.
I've deleted those items, since we've no hope of implementing them.
I think we should mark merge obstructions as tree conflicts, and
support only --accept=working when resolving them.
>
>> 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.
Agreed. Correction:
[Merge: Add-with-history the SOURCE-LEFT item]
(I also corrected the other "base" resolutions below.)
>
>> 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: Delete the victim. Add-with-history the SOURCE-LEFT item]
>>
>> 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:
add-with-history the SOURCE-LEFT item]
>>
>> 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. [Update: Finish
adding the new item.] [Merge: add-with-history the SOURCE-LEFT
item]
>>
>> 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.
We'll let those sleeping dogs lie, if we can, and support only
--accept=working for obstructed tree conflicts, as explained above.
Cheers,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
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-04 00:27:01 CET