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

Re: Tree conflict after a simple delete

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 23 Sep 2009 13:24:56 +0100

On Wed, Sep 23, 2009 at 01:45:47PM +0200, Stein Somers wrote:
> Stefan Sperling wrote:
> > As far as tree conflicts are concerned, Subversion does not know the
> > difference between delete and move, yet. Any delete is therefore
> > treated as a potiential move, which can lead to false positives.
> I don't quite understand this (nor the whole "true rename" saga). In the case
> here, a merged delete (log message "uh this file is not used at all")
> conflicts with a local edit (log message "this file is super but has a typo
> and therefore was inactive"). Are you saying svn would silently overrule the
> local edit if it was sure the delete was a genuine delete?

No, I didn't mean to say that. I didn't look too closely at the log message
and the exact conflict. An edited file vs. a deleted file is certainly
a conflict and one of two possible outcomes needs to be chosen by the
user (keep the file, or delete it).

> The contrary should be true, in my opinion. Svn should only silently accept
> the delete if it is sure the file is copied and report a conflict for each of
> the copies, or something.

A "false positive" in this context is where svn is reporting a tree conflict
while there is in fact no conflict, because there is only one logical
merge result. This can happen e.g. if both sides delete a file.
The logical merge result is to delete the file, since both sides agree
on deletion. This should not conflict, but it does conflict currently,
because either or both sides could be a move, and Subversion has no way
of telling the difference between a move and a delete, yet.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-23 14:25:55 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.