Should deletes conflict with mods?

[William Uther <wi...@cse.unsw.edu.au>]

Alo,

Consider the following use case:

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.

In my mind, the update should cause a conflict.  At present subversion 
simply removes the file from .svn/entries during the update, and leaves 
the locally modifed file around.  I wonder if this shouldn't be marked 
as a conflict (somehow - possibly with a note in the entries file).

There are two reasons why the current behaviour is a problem:

i) It is easy for the conflict to go unnoticed; especially since,
ii) the person updating now has a file in their working copy which is 
not checked in.  While this is normal for generated files, for source 
it can be a problem.  You can have a build that succeeds locally and 
yet breaks the repository.

Note, I'm guessing that this behaviour also shows up when a directory 
is "moved" using copy and delete (although it would cease being 
relevant when moving is changed: 
http://subversion.tigris.org/issues/show_bug.cgi?id=898).  The old dir 
is copied, and then any local mods are silently left as untracked files 
in the working copy.

Do others also think there should be a conflict here?  I couldn't find 
an issue about this.  Should I file one?

Here is a full example of the current (well relatively recent) 
behaviour using delete:

% svn --version
svn, version 0.17.0 (dev build)
    compiled Jan 21 2003, 14:21:21
% mkdir demo
% cd demo
% svnadmin create repos
% svn co file://`pwd`/repos wc1
Checked out revision 0.
% cd wc1
% cat > file
A line of text
% svn add file
A         file
% svn commit -m "added a file"
Adding         file
Transmitting file data .
Committed revision 1.
% cd ..
% svn co file://`pwd`/repos wc2
A  wc2/file
Checked out revision 1.
% cd wc2
% svn rm file
D         file
% svn commit -m "removed file"
Deleting       file

Committed revision 2.
% cd ..
% cd wc1
% cat  > file
A second line of text
% svn up
D  file
Updated to revision 2.
% ls
file
% svn st
?      file

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

Re: Should deletes conflict with mods?

[Ben Collins-Sussman <su...@collab.net>]

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 <wi...@cse.unsw.edu.au> writes:

> On Saturday, February 8, 2003, at 08:19  AM, Ben Collins-Sussman wrote:
> 
> > William Uther <wi...@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

Re: Should deletes conflict with mods?

[William Uther <wi...@cse.unsw.edu.au>]

On Saturday, February 8, 2003, at 08:19  AM, Ben Collins-Sussman wrote:

> William Uther <wi...@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

Re: Should deletes conflict with mods?

[Ben Collins-Sussman <su...@collab.net>]

William Uther <wi...@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.
> 
> In my mind, the update should cause a conflict.  At present subversion
> simply removes the file from .svn/entries during the update, and
> leaves the locally modifed file around.  I wonder if this shouldn't be
> marked as a conflict (somehow - possibly with a note in the entries
> file).

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?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org