Stefan Sperling <stsp_at_elego.de> wrote on 04/20/2008 09:56:56 AM:
> On Sun, Apr 20, 2008 at 01:32:17AM +0200, Nico Schellingerhout wrote:
> > Hi tree-conflict-crew,
> >
> > Piet-Hein and I looked at the 30 test cases that Julian defined, and
> > talking
> > through it, we found cases missing, and we saw the number of
> cases blowing
> > up even further. I therefore tried to come up with a simpler model
(see
> > analysis below).
> >
> > Tree conflict case analysis:
> > ============================
> >
> > Let's start by enumerating all the cases:
> >
> > target \ source | mod add del rep
> > ----------------+-----------------
> > mod | M X C C
> > add | X C X X
> > del | C X C C
> > rep | C X C C
> >
> > Legend:
> > M = merge (=text merge for files, dir merge for dirs)
> > X = can't happen
>
> Could you elaborate on the cases that can't happen?
>
> For example, it might well be that during a merge,
> the source of the merge defines a delete on a file,
> yet the target working copy has the same file locally
> added.
I'm not sure I understand that case: if the source deletes
a file, the target must have the file as well, unless it
has been deleted as well or is replaced by another file.
I don't see how you could add a file if the file is
already there.
In my table I tried to indicate "the full set of changes
unique to the source/target branch", which includes possibly
local modifications on a working copy. In other words, I
considered the full history of the two branches, in which
case I don't see how this can happen.
> Same goes for replace/delete and the other way
> around, where the merge wants to add a file to a path
> which is scheduled for deletion in the working copy.
Ok. If I understand you correctly, a use case could be:
source:
r1001 A foo.txt
target:
r1002 A foo.txt
r1003 D foo.txt (or, perhaps just a local mod, not yet committed)
after which the user tries to merge r1001 from source to target.
Now the question is: is this a valid merge or is this a tree
conflict? Naively, the fact that foo.txt has been deleted makes
the path available for the add from the source again, so the merge
is safe. However, If the merge had taken place after r1002, there
would have been a tree conflict.
Looking at the complete history on target, this would trigger a
tree conflict because of the add in r1002, according to the table,
and that would probably also be the safest approach.
Given that tree conflict detection will initially be a lot simpler,
I think the use case could be allowed to merge ok (apart from the
obstruction problems I mentioned in the original post).
Does this type of reasoning make sense to you?
>
> Note that I say "in the working copy" because in the
> actual target branch, the schedule add/delete isn't possible.
>
> Note that I would be fine with requiring users to merge
> into "pristine" working copies for the first generation
> of tree-conflict detection if that simplifies things for us.
> Have we ever discussed this?
Me as well. IMNSHO, merging onto modified WCs is a bad practice,
and evil things may happen to people who try :)
(svnmerge.py actually checks on this and refuses a merge if there
are local changes!).
>
> > Desired behaviour (apart from raising the conflict):
> >
> > 1. del onto mod:
> > -> Do not do the delete on the working copy
> >
> > 2. rep onto mod:
> > -> Do not do the replace on the working copy
> >
> > 3. add onto add:
> > -> Do not perform the add from the repo (and keep the add in the
> > working copy)
> >
> > 4. mod onto del:
> > -> file: Put modified file from archive unversioned into WC
simplify
> > merging
> > -> dir: Leave scheduled for deletion dir in WC
> >
> > 5. del onto del:
> > -> file: delete the file
> > -> dir: leave dir scheduled for deletion
> >
> > 6. rep onto del: (Treat as case 4)
> > -> file: Put replaced file from archive unversioned into WC
simplify
> > merging
> > -> dir: Leave scheduled for deletion dir in WC
> >
> > 7. mod onto rep:
> > -> Do not do the modify on the working copy
>
> Some questions that come to mind I'll just note here
> so they don't get lost:
>
> Can we unambiguously tell "replace" in the working copy
> apart from "move" in the working copy? Is the target
> for the first a file added-with-history and for the
> other a file with only schedule-add? Does the current
> working copy code behave consistently with respect to
> this in *all* cases?
Perhaps we can't, but the reasoning behind the C2 behaviour for merging
onto deletes was that in those case you actually have a place to store
the file, and make it easier for the user to merge the changes.
Come to think of it, wouldn't it be more consistent to load the WC
with the usual helper files, and extend that to tree conflicts and
dirs?
From the Subversion book:
> sandwich.txt
> sandwich.txt.mine
> sandwich.txt.r1
> sandwich.txt.r2
for update/switch and
> filename.working
> filename.left
> filename.right
for merge.
That would lead to the following behavior table:
target \ source | mod add del rep
----------------+-----------------
mod | M X Ca Cb
add | X Cc X X
del | Cd X Ce Cd
rep | Cb X Ca Cb
Legend:
Ca: filename.working + filename.left
Cb: filename.working + filename.left + filename.right
Cc: filename.working + filename.right
Cd: filename.left + filename.right
Ce: filename.left
Note that the only differences between the Ca-Ce behaviors is what
files are dropped in the WC. The decision on what files to drop is
based purely on the absence/presence of the path in the left, right,
and working version of the tree. This should make the implementation
easier I guess.
The advantage of that approach is also that it should be pretty clear to
the user, because IMHO it would be a consistent re-use of a known concept.
>
> > 8. del onto rep:
> > -> Do not do the delete on the working copy
> >
> > 9. rep onto rep:
> > -> Do not do the replace from the source on the working copy
> >
> > I hope this helps (the model feels sound to me, but it may be a tad
too
> > simple). I hope it is simple enough to implement as well ...
>
> I'd like things to get simpler as well. Your proposal sounds
> fine to me expect for the points I've raised in the above
> paragraphs (which I hope we'll able to handle somehow).
>
> Also, would you mind if we continued discussion on
> dev_at_subversion.tigris.org ?
Done.
- Nico
Received on 2008-04-20 11:54:30 CEST