Re: Unnoticed conflicts when moving or deleting

On Apr 16, 2005, at 2:42 AM, Ingo Adler wrote:

> Szenario:
> Markus moves a file and commits his changes.
> Andreas changes the same file in the mean time, updates and commits.
> There is no conflict no, warning - nothing. The changed files of
> Andreas are not unter subversion's control anymore - very bad.

This scenario has been described over and over. It's one of our
classic examples of why subversion needs "true renames" rather than
copy/delete actions. It's even documented in our merge-tracking
brainstorm doc, in section C-2:

   http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt

>
> This wouldn't happen in CVS. A changed but deleted file is marked as a
> conflict, which is probably the best way except defining a new state.

It's not marked as a conflict, but the data isn't lost either. The
file becomes unversioned.

> The developers who get conflict, know that they have a problem and
> that they have to handle it.

Well, running 'svn status' will show the old file as '?', so there's
still an indication that *something* is new in the working copy.

>
> What's the solution?
>

Either wait for svn to implement true move operations, or start a
discussion about how libsvn_wc might be able to mark the file
conflicted. It would require some new design; up till now, 'C' always
represented textual-conflicts, not tree-conflicts.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 16 16:07:09 2005