On Thu, Nov 26, 2009 at 08:01:30PM +0100, Daniel Näslund wrote:
> What I want to do
> =====================
> I'm trying to sort out the different tree conflict scenarios for a
> possible tree conflict resolver as described in #3144 [1].
>
> As a first step I'm looking at conflicts on files when using update. I
> have attached a script for testing. Run './utc.sh list' for info on how
> to use it.
>
> I've used the classification described in
> notes/tree-conflicts/resolution.txt and compared it with all the
> possible tree conflict scenarios as outlined in stsp:s thesis [2] on
> tree conflicts.
[...]
Intro
======
This thread was basically about me trying to convince myself that
the approach in notes/tree-conflicts/resolution.txt holds. Here's an
attempt to describe the state the WC is in during the different "file
update tree conflicts".
The categories and names of actions are taken from resolution.txt. I
expect the names of the actions to change but I'm hoping to use the
existing classification for a spec eventually. If someone has any
objections to that I'd be glad to hear them now!
When I describe the MINE action I say that WORKING-TARGET is in a state
that equals WORKING. I mean that some scheduling has been changed but
that they are both supposed to do the same thing. I haven't confirmed in
the code and design doc that this is always the case. In resolution.txt
there's a paragraph saying:
[[[
* When "svn update" or "svn switch" raises a tree conflict, it shall update
the victim's "base" version from OLD to THEIRS, and leave the "working"
version in a state that would be committable (but for the explicit check
that prevents committing an item marked as in conflict) and that, if
committed, would restore the item to how it looked in "mine". This may
involve changing the scheduling of the item, e.g. to be re-added if "update"
applied a delete.
]]]
Does the tree conflict code do that? When running my test cases I could
just use 'svn resolved <file>' but I may have missed some edge cases.
A bit early but I was wondering about this piece from resolution.txt:
[[[
"Options" lists resolution options that ought to be available. The
resolution options "THEIRS" and "MINE" should be available in every case (so
that a user can resolve a whole tree at once with one of those options) and
should be implemented internally. Any other options listed here may be
recipes for the user to apply manually. These recipes are starting from the
state in which the WC should be left by Subversion after raising a conflict.
]]]
Is this still the way we want it? THEIRS and MINE is handled in our
code, the other options is text that explains what to do and leaves it
to the user to do it?
Categories of conflicts
========================
1. Locale add, incoming add
2. Locale del, incoming del
3. Locale del, incoming edit
4. Locale edit, incoming del
1. Locale add, incoming add
============================
Some use cases:
- I have already applied the patch - their item is identical to mine.
-> want to do it just once -> THEIRS.
- Two different new items happened to be given the same name. ->
accept theirs & rename mine -> RENAME-MINE.
- I was doing roughly the same thing but the item is a bit different.
-> merge the two items -> manual 2-way merge (or 3-way if both are
w/hist and it's the same copy-from source) -> MERGE.
THEIRS
--------
Replace <file> in WORKING with the new BASE that comes in during the
update.
*Problems*: We may need to undo a local move or copy operation with
destination <file>.
MINE
-----
WORKING-TARGET is already changed to a state that means the same as our
previous WORKING.
*Problems*: Are we guarenteed that this always holds? Can the
rescheduling destroy the semantics of the change?
RENAME-MINE
------------
Move the WORKING <file> to <renamed> and replace <file> with the new
BASE that comes in during update.
MERGE
------
Merge BASE <file1> onto WORKING <file2>. Delete <file1> from WORKING.
2. Locale del, incoming del
============================
Some use cases:
- Already applied the patch -> want to do it just once -> THEIRS.
- Renamed to two different names -> want to undo Their renaming and
make it like Mine, as if we had a "Choose Mine" option that worked
on whole rename operations. -> RENAME.
THEIRS
-------
Delete the WORKING <file>. If the WORKING <file> has been moved to
<moved> then delete <moved> too. WORKING <file> is supposed to be
deleted in all cases so perhaps there's no need to specify it here?
MINE
-----
WORKING-TARGET is already changed to a state that means the same as our
previous WORKING.
RENAME
-------
Rename WORKING <file> to <renamed>. Merge BASE <file> onto WORKING
<renamed> if there are changes. Remove BASE <file>?
3. Locale del, incoming edit
============================
Some use cases:
- Locally renamed -> want to apply the incoming mod to a different
item -> ELSEWHERE.
THEIRS
-------
Replace the deleted WORKING <file> with edited BASE <file>. If WORKING
<file> has been moved to WORKING <moved>, delete <moved>
MINE
-----
WORKING-TARGET is already changed to a state that means the same as our
previous WORKING.
ELSEWHERE1
-------------
If WORKING <file> has been moved to WORKING <moved>. Merge BASE <file>
onto WORKING <moved>. Does this preserve history?
ELSEWHERE2
-----------
TODO:
4. Locale edit, incoming del
============================
Some use cases:
- The incoming change is (part of) a rename -> want to transfer my
local mod to the renamed item -> MOVE-MY-MODS.
THEIRS
-------
Remove WORKING <file>. If WORKING <file> has been moved to WORKING
<moved>. Replace WORKING <moved> with BASE <moved>.
MINE
-----
WORKING-TARGET is already changed to a state that means the same as our
previous WORKING.
MOVE-MY-MODS1
-------------
If BASE <file> has been moved to BASE <moved>: Merge WORKING <file> onto
BASE <moved>. Delete WORKING <file>.
MOVE-MY-MODS2
--------------
If BASE <file> has been moved to BASE <moved>: Merge BASE <moved> onto
WORKING <file>. Delete BASE <moved>. Move WORKING <file> to WORKING
<moved>.
--
Daniel
