On Sun, Apr 20, 2008 at 11:54:12AM +0200, Nico Schellingerhout wrote:
> > 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.
OK, I agree. I must admit my reasoning didn't go as deep as yours :)
> > 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?
Yes it does. Thanks for clarifying.
> > 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!).
Good. Let's see if others agree with us on this point...
> 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.
Yes, we can do that. But I'd rather delay this to the second
phase. Because frankly, the current state of how the user interfaces
with tree conflicts is lacking beyond belief.
So since we need to fix the UI anyway, I think we should focus on
getting proper detection code in place for now, and not change
the current UI (which is fine for testing).
--
Stefan Sperling <stsp_at_elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
- application/pgp-signature attachment: stored
Received on 2008-04-20 14:27:19 CEST