You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Richard Biffl <su...@blacklettersoftware.com> on 2010/08/08 19:58:52 UTC
Cannot delete directory after deleting included file
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.
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.
The way to prevent this problem, I've learned, is to update the working copy
after I commit the deletion of the single file. But that's not intuitive,
especially when I am the only user and I'm making changes from just one working
copy. It seems wrong that I should need to update immediately after I commit.
Here is a list of commands that shows the problem. It's in Windows cmd:
[starting with empty repository \svn\repo1]
$ mkdir work1
$ svn checkout file:///svn/repo1 work1
$ mkdir work1\dir1
$ echo blah > work1\dir1\file1
$ echo blah > work1\dir1\file2
$ svn add work1\dir1
$ svn commit work1 -m "Created directory with 2 files."
$ svn delete work1\dir1\file1
$ svn commit work1 -m "Deleted dir1\file1."
$ svn delete \work1\dir1
$ svn commit work1 -m "Deleted dir1 and dir1\file2."
Deleting \work1\dir1
svn: Commit failed (details follow):
svn: Directory '/dir1' is out of date
Richard
Re: Cannot delete directory after deleting included file
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Aug 8, 2010 at 3:58 PM, Richard Biffl
<su...@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.
Re: Cannot delete directory after deleting included file
Posted by Richard Biffl <gm...@blacklettersoftware.com>.
"Johan Corveleyn" <jc...@gmail.com> wrote in message
news:AANLkTikwGYBH37J97rbEMcyQRUE08UvauYJiX=kha0hS@mail.gmail.com...
> This looks similar to issue 3526:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3526 - Commit of
> newly added file followed by move (or delete) of parent dir causes
> tree conflict
>
> A couple of relevant discussions which may provide some additional
> insight:
> -
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388307
> - http://svn.haxx.se/dev/archive-2010-03/0496.shtml
> - http://svn.haxx.se/users/archive-2010-06/0033.shtml
>
> I'm not sure what the current plan is for that issue. As far as I
> understand, the out-of-dateness can not be avoided. It is a
> consequence of the "mixed-revision working copy" system that SVN uses.
>
> I think it would already help a lot of there would be no tree conflict
> when updating (which is what issue 3526 is actually about). But I'm
> not sure if someone is actively working on this.
>
> From one of the mail threads above, a good workaround to avoid this
> issue is to always update a directory before you move or delete it
> (you don't have to update the entire working copy, just the part you
> are about to move/delete).
Thank you for making that connection, Johan. I agree, that issue does look
related to mine. I wish I knew enough about the internals of subversion to
suggest or contribute a fix.
Richard
Re: Cannot delete directory after deleting included file
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Aug 8, 2010 at 9:58 PM, Richard Biffl
<su...@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.
>
> 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.
>
> The way to prevent this problem, I've learned, is to update the working copy
> after I commit the deletion of the single file. But that's not intuitive,
> especially when I am the only user and I'm making changes from just one working
> copy. It seems wrong that I should need to update immediately after I commit.
>
> Here is a list of commands that shows the problem. It's in Windows cmd:
>
> [starting with empty repository \svn\repo1]
> $ mkdir work1
> $ svn checkout file:///svn/repo1 work1
> $ mkdir work1\dir1
> $ echo blah > work1\dir1\file1
> $ echo blah > work1\dir1\file2
> $ svn add work1\dir1
> $ svn commit work1 -m "Created directory with 2 files."
> $ svn delete work1\dir1\file1
> $ svn commit work1 -m "Deleted dir1\file1."
> $ svn delete \work1\dir1
> $ svn commit work1 -m "Deleted dir1 and dir1\file2."
> Deleting \work1\dir1
> svn: Commit failed (details follow):
> svn: Directory '/dir1' is out of date
This looks similar to issue 3526:
http://subversion.tigris.org/issues/show_bug.cgi?id=3526 - Commit of
newly added file followed by move (or delete) of parent dir causes
tree conflict
A couple of relevant discussions which may provide some additional insight:
- http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388307
- http://svn.haxx.se/dev/archive-2010-03/0496.shtml
- http://svn.haxx.se/users/archive-2010-06/0033.shtml
I'm not sure what the current plan is for that issue. As far as I
understand, the out-of-dateness can not be avoided. It is a
consequence of the "mixed-revision working copy" system that SVN uses.
I think it would already help a lot of there would be no tree conflict
when updating (which is what issue 3526 is actually about). But I'm
not sure if someone is actively working on this.
Re: Cannot delete directory after deleting included file
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Aug 8, 2010 at 9:58 PM, Richard Biffl
<su...@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.
>
> 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.
>
> The way to prevent this problem, I've learned, is to update the working copy
> after I commit the deletion of the single file. But that's not intuitive,
> especially when I am the only user and I'm making changes from just one working
> copy. It seems wrong that I should need to update immediately after I commit.
>
> Here is a list of commands that shows the problem. It's in Windows cmd:
>
> [starting with empty repository \svn\repo1]
> $ mkdir work1
> $ svn checkout file:///svn/repo1 work1
> $ mkdir work1\dir1
> $ echo blah > work1\dir1\file1
> $ echo blah > work1\dir1\file2
> $ svn add work1\dir1
> $ svn commit work1 -m "Created directory with 2 files."
> $ svn delete work1\dir1\file1
> $ svn commit work1 -m "Deleted dir1\file1."
> $ svn delete \work1\dir1
> $ svn commit work1 -m "Deleted dir1 and dir1\file2."
> Deleting \work1\dir1
> svn: Commit failed (details follow):
> svn: Directory '/dir1' is out of date
This looks similar to issue 3526:
http://subversion.tigris.org/issues/show_bug.cgi?id=3526 - Commit of
newly added file followed by move (or delete) of parent dir causes
tree conflict
A couple of relevant discussions which may provide some additional insight:
- http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388307
- http://svn.haxx.se/dev/archive-2010-03/0496.shtml
- http://svn.haxx.se/users/archive-2010-06/0033.shtml
I'm not sure what the current plan is for that issue. As far as I
understand, the out-of-dateness can not be avoided. It is a
consequence of the "mixed-revision working copy" system that SVN uses.
I think it would already help a lot of there would be no tree conflict
when updating (which is what issue 3526 is actually about). But I'm
not sure if someone is actively working on this.
>From one of the mail threads above, a good workaround to avoid this
issue is to always update a directory before you move or delete it
(you don't have to update the entire working copy, just the part you
are about to move/delete).
--
Johan