RE: New tree conflicts for obstructions?

Technically the delete is already scheduled when the tree conflict is added.
Without a specific obstruction-conflict this was the best thing we could do
to allow continuing the update without dropping the data.

But I agree that we should improve the conflict resolution in this case.
(And probably for many other tree conflicts too).

The best way to resolve this conflict on 1.7.x would be reverting as that
brings 'back' the updated file.

                Bert

From: Mark Phippard [mailto:markphip_at_gmail.com]
Sent: vrijdag 11 november 2011 19:28
To: Subversion Development
Subject: New tree conflicts for obstructions?

It looks like SVN 1.7 added some new tree conflicts. For example, when
doing an update and SVN wants to add a file that already exists it creates a
tree conflict.

$ svn status
D C .settings/org.eclipse.wst.common.project.facet.core.xml
> local unversioned, incoming add upon update
D C .settings/org.eclipse.wst.common.component
> local unversioned, incoming add upon update
Summary of conflicts:
  Tree conflicts: 2

We need to add support for this in Subclipse. From what we can see the only
resolve option is to accept=working and this resolves by scheduling a
delete. This makes very little sense and seems like a bug.

What I normally do is use svn update --force which does not produce a tree
conflict and instead just slides the added file into pristines so that only
local differences now show up as a local modification that can be committed
or reverted. It seems like resolve needs to support some resolutions like
that, which I guess would just be an option to mark the conflict resolved
but do nothing.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/