On Sun, Aug 8, 2010 at 3:58 PM, Richard Biffl
<subversion-user-ml_at_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.
Received on 2010-08-08 22:37:33 CEST