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 Sat Feb 8 00:01:27 2003