[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Deleting an Added (but not committed) Tree

From: Peter Davis <peter_at_pdavis.cx>
Date: 2002-08-11 21:18:47 CEST

On Saturday 10 August 2002 04:07, Nuutti Kotivuori wrote:
> Just a note - to undo a scheduled, but not yet committed add - one
> should use 'svn revert'.

You are right. But for consistency, rm should work as well, if not because
that was the logical command to use in my opinion, but because it works for
files, and (mostly because) it also works for directories that don't have any
subdirectories.

$ svn touch file
$ svn add file
$ svn rm --force file
[works]

$ svn mkdir a
$ svn rm --force a
[works]

$ svn mkdir a a/b
$ svn rm --force a
[doesn't work, and also creates all kinds of cleanup problems; I have to do a
complicated and non-obvious svn cleanup to make my wc usable for this or any
other operation]

Therefore, I still think this is a bug, although you give a good workaround.

> And indeed:
>
> $ svn mkdir a a/b
> A a
> A a/b
> $ svn revert a
> Reverted a
> $ rmdir a/b a
> $ svn up
> At revision 5.
>
> No problems.

Well, it does have the problem that revert does not actually delete the
physical directories, like rm does. Maybe that's why I wanted to use rm in
the first place. But it's close enough - I can just use regular 'rm -rf a'
after reverting to delete all traces.

> Your other comment has a point though - and this comment
> has a point about broken 'svn rm' behaviour - but the overall thing
> which you are trying to achieve does get done with a different
> command.

I will file bugs on both of these unless someone says otherwise. Just wanted
to bring them up here first.

-- 
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 11 21:19:18 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.