You know, this email really ought to be attached to issue 1066. It's
*exactly* the kind of discussion that the issue needs.
William Uther <willu.mailingLists@cse.unsw.edu.au> writes:
> On Saturday, February 8, 2003, at 08:19 AM, Ben Collins-Sussman wrote:
>
> > William Uther <willu.mailingLists@cse.unsw.edu.au> writes:
> >
> >> Two people, A and B, have a file checked out.
> >> Person A deletes the file.
> >> Person B edits the file.
> >> Person A commits.
> >> Person B updates.
> >
> > I agree, in my own mind, this has always been a what I call a "tree"
> > conflict rather than a textual conflict. There are number of "tree"
> > conflicts that can arise by permuting any two actions from {add,
> > delete, modify}. If you bother to write out all the permutations,
> > most of the scenarios result in failed commits. But the scenario you
> > point out has always troubled me.
> >
> >> Do others also think there should be a conflict here? I couldn't find
> >> an issue about this. Should I file one?
> >
> > The question is, how *should* the conflict be flagged? Do you have a
> > better idea than the status quo?
>
> Hmm. This is off the top of my head, and my understanding of wc
> operations is not exact, but...
>
> When you are merging a deleted file and a modified file, the entry for
> the file is set to a new state - conflicted-delete. The file in the
> working copy becomes the modified file. (Note that it doesn't matter
> if the delete was local and the modify remote, or vice-versa -- this
> may mean that the "modified" file has to be created locally.) While
> marked as "conflicted-delete", the file is conflicted.
>
> The user the edits or deletes the file.
>
> The user then runs "svn resolve" on the file. This would be one case
> where resolve does something that cannot be done another way. If the
> file is not in the working copy, then it is removed from the entries
> file or marked deleted (depends upon whether the delete happened
> locally or remotely). If the file is in the working copy, then it is
> either left as a normal file, or marked as added with history (again
> depending upon whether the delete happened locally or globally).
>
> Here are four examples: (note, I think we might need two
> conflicted-delete states to detect whether the deleted file is local
> or remote)
>
> A) local edit, keep file
>
> Two people, A and B, both have the file "file" checked out.
> Person A deletes the file and commits.
> Person B edits the file and updates.
>
> Person B's copy of file is changed to state "conflicted-delete-A".
> Their copy of the file remains in their working copy.
>
> Person B decides to keep the file. They edit it and run "svn
> resolve". resolve notices the file exists, and changes its state to
> "add with history". Rationale: The file has been deleted in the
> repos. To recover it we need to add it back, with history.
>
> B) local edit, remove file
>
> Two people, A and B, both have the file "file" checked out.
> Person A deletes the file and commits.
> Person B edits the file and updates.
>
> Person B's copy of file is changed to state "conflicted-delete-A".
> Their copy of the file remains in their working copy.
>
> Person B decides to remove the file. They delete it. They run "svn
> resolve". resolve notices the file is missing, and removes it from
> the working copy - we're now no longer conflicted. This case is
> different to many other working copy operations in that we now know we
> are the same as the repository. Hence we can simply pretend we're now
> all committed. This means that svn revert cannot revert, but I'm not
> sure what reverting an update means anyway.
>
> C) local delete, keep file
>
> Two people, A and B, both have the file "file" checked out.
> Person A edits the file and commits.
> Person B deletes the file and updates.
>
> Person B gets a copy of the edited file in state "conflicted-delete-B".
>
> Person B decides to keep the file. They edit it and run "svn
> resolve". resolve notices the file exists, and changes its state to
> "modified".
>
> D) local delete, delete file
>
> Two people, A and B, both have the file "file" checked out.
> Person A edits the file and commits.
> Person B deletes the file and updates.
>
> Person B gets a copy of the edited file in state "conflicted-delete-B".
>
> Person B decides to delete the file. They delete it and run "svn
> resolve". resolve notices the file is missing, and changes its state
> to "deleted".
>
>
>
> I assume that 'merge' would always use the C/D cases as the file has
> not actually been deleted in the repos in the current version.
> Actually, this brings up another wrinkle... What happens if:
>
> Two people, A and B, both have the file "file" checked out.
> Person A edits the file and commits.
> Person A deletes the file and commits.
> Person B edits the file and updates.
>
> Should person A's first set of edits get merged with person B's edits
> as well as having the "tree conflict". Note that this would mean you
> could have BOTH a tree conflict and a normal conflict in the same file
> at the same time. :) Wheeee!
>
> Later,
>
> Will :-}
>
> --
> Dr William Uther National ICT Australia
> Phone: +61 2 9385 6926 School of Computer Science and
> Engineering
> Email: willu@cse.unsw.edu.au University of New South Wales
> Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 12 16:18:48 2003