[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Unnoticed conflicts when moving or deleting

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-04-16 16:05:00 CEST

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:


> 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

This is an archived mail posted to the Subversion Dev mailing list.