[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 11:43:15 +0100

On Wed, Sep 23, 2009 at 11:09:05AM +0100, Giulio Troccoli wrote:
> I hope someone can help me understand what it's going on.
> I am using SVN 1.6.5 on RHEL4 with http access.
> We have few development streams, one for each version of the product we still support. All new features are developed in a work-in-progress stream and then merged.
> Someone deleted a file in WIP but the merged threw out a tree conflict and I don't unserstand why.
> This is what I have done
> ln1sub01 gtroccol>svn co http://localhost/svn-icon/5.31/test/src/ic/ud gt
> ...
> Checked out revision 5983
> ln1sub01 gtroccol> cd gt
> ln1sub01 gt> svn st
> ln1sub01 gt> svn log -c5971 -v http://localhost/svn-icon/wip/src/ic/ud
> ------------------------------------------------------------------------
> r5971 | ccamacho | 2009-09-16 14:45:31 +0100 (Wed, 16 Sep 2009) | 1 line
> Changed paths:
> D /wip/src/ic/ud/icudcc31.c
> M /wip/src/ic/ud/icudct31.c
> P00016927: (WIP) Removal of Indexation and RebasedIndexation fields in CGTTransaction and CGTCalc file
> ------------------------------------------------------------------------
> ln1sub01 gt> svn merge -c5971 http://localhost/svn-icon/wip/src/ic/ud
> --- Merging r5971 into '.':
> U icudct31.c
> C icudcc31.c
> Summary of conflicts:
> Tree conflicts: 1
> ln1sub01 gt> svn st
> M .
> C icudcc31.c
> > local edit, incoming delete upon merge
> M icudct31.c
> I don't understand why I have a tree conflict on icudcc31.c. The message say "local edit" but the file hasn't been changed, as the first svn st command showed.

During merge (but not during update), a "local" edit may also be an
edit in the target branch's history, rather than an edit in the working copy.

> I have seen other posts in the ML regarding unexpected tree conflicts but they are usually about deleting of directories not files, or merging a delete twice in both directions (from trunk to branch and then from branch to trunk), or renaming/moving a file. Now I know this last case is similar to mine, as that it's just a delete and an add in Subversion, but, well, it should work :-)

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.

Do these hints help?



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-23 12:44:11 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.