On Thu, Dec 17, 2009 at 01:09:56PM -0600, Ryan Schmidt wrote:
>
> On Dec 17, 2009, at 12:55, Dave Westerman wrote:
>
> > I'm having problems with a directory that has been deleted, but is preventing me from being able to commit changes to SVN.
> >
> > I created a branch, and am now done with it. I've tried to merge it back into the trunk, for which I have a brand new checked-out working copy. The way SVN is set up here, I can't do a 'merge --reintegrate' (although I don't know that this has anything to do with my issue).
> >
> > I did the merge, and dealt with the conflicts, except for this one conflict with a directory that used to exist ('xml-ND'). I deleted the directory after I created the branch - from both the trunk and the branch. But the merge flagged it as a conflict, even though it doesn't exist in the trunk or the branch or my working copy.
> >
> > I tried to do a commit, and got the following error message:
> > svn: Commit failed (details follow):
> > svn: Aborting commit: '/home/dlwester/SVN/MiddlewareMigrationScripts/WasUcmPlugin/xml-ND' remains in conflict
> >
> > I tried to delete this subdirectory, with 'svn delete', in the trunk and the branch and the working copy, but it tells me it doesn't exist. I even used the '--force' option, which had no effect.
> >
> > I looked in the .svn/entries file, and see this entry for the subdirectory:
> > ((conflict xml-ND dir merge deleted deleted (version https://svn.cs.opensource.ibm.com/svn/zgears 4 3610 MiddlewareMigrationScripts/WasUcmPlugin/xml-ND dir) (version https://svn.cs.opensource.ibm.com/svn/zgears 4 4273 MiddlewareMigrationScripts/WasUcmPlugin.branch.ND/xml-ND dir)))
> >
> > I don't know what to do at this point. How can I get rid of this "phantom" entry for this subdirectory, so that SVN will allow me to do the commit?
>
> Tell Subversion the conflict is resolved:
>
> svn resolved /home/dlwester/SVN/MiddlewareMigrationScripts/WasUcmPlugin/xml-ND
That's right.
Dave, you've hit a known false-positive tree-conflict case.
You see, this would have been a true conflict if you had renamed one of the
directories and deleted the other, or renamed both of them to different
destination paths. Because Subversion cannot [yet] tell the difference
between a rename and a deletion, it has to treat deletion on both sides
as a conflict. Subversion knows that a conflict might have happened,
but it lacks vital information to make an informed decision. So it sets
up a warning sign, in form of a conflict marker, and leaves judgement
of the situation to you.
Since you really meant to delete the directory on both branches, there is
no real conflict, and you can just mark the conflict as resolved and move on.
We hope to start with gradually improving this behaviour once the new
working copy implementation has been released. It will set the foundation
for making further improvements in this area without causing serious
damage to the sanity of Subversion's developers.
Stefan
Received on 2009-12-17 22:53:33 CET