On Sun, Aug 8, 2010 at 3:58 PM, Richard Biffl <subversion-user...@blacklettersoftware.com> wrote: > If I delete a file from a directory in my working copy, and commit the > deletion, > and then delete the directory that held the deleted file, I cannot commit the > working copy. I get a message instead that the directory is out of date.
Yeah, this is inherent in Subversion's "central repository" model. Some change by someone else or even by you in another repository may have profoundly altered the contents of that directory already, deleted it already, changed it to an "svn:external" created directory or symlink. So the synchronization is critical to prevent conflicts between your changes and those already in the repo. > At that point, I cannot revert the directory deletion, and if I try to update > the working copy, I am told I have a tree conflict. Well, you've got other issues. If you want "work1" to be the top of your working copy, don't do "mkdir work1" first. Just do "svn checkout file:///svn/repo1 work1", and the work1 directory should be created for you, instead of potentially being created as a subdir of your existing work1 directory. Even if it happens to work in your environment, it's a potentially confusing programming syntax. Second, doing "svn add" is not reverting "svn del". It's yet another operation on top of the modified local configuration, to be processed in order, and it's begging for confusion. Do "svn revert" to actually change something back that you haven't committed yet.
