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

Re: svn copy after forced removal of copied file

From: Ryan Schmidt <subversion-2006c_at_ryandesign.com>
Date: 2006-08-01 14:21:38 CEST

On Aug 1, 2006, at 10:19, Kevin Musker wrote:

>>> If I svn cp a file from the repository, and subsequently delete it,
>>> I get an error if I try to copy it in again -
>>>> svn cp $SVNROOT/cheese.cc .
>>>> svn rm --force cheese.cc
>>>> svn cp $SVNROOT/cheese.cc .
>>> svn: 'cheese.cc' is not under version control
>> User error. Don't do that.
>> If you copied the file
>> svn cp $SVNROOT/cheese.cc .
>> and then decided, before committing, that you didn't mean to copy it
>> after all, don't
>> svn rm --force cheese.cc
>> Instead, revert the copy:
>> svn revert cheese.cc
> OK, granted, I should have used revert instead.
> But no amount of user error (other than modifying files in the .svn
> directory) should result in
> a working copy being in an inconsistent state. If --force should only
> really be used in exceptional
> circumstances, this should be documented in the rm section, not
> just in
> the general svn section
> From the svnbook:
> "The command will not remove any unversioned or modified items; use
> the
> --force switch to override this behavior."
> This doesn't say anything about not using --force for copied files.
> The
> command line app even suggests the use of --force:
>> svn rm cheese.cc
> svn: Use --force to override this restriction
> svn: 'cheese.cc' has local modifications
> To people experienced in using svn, it's obvious that revert should be
> used. But to someone used to using a shell in unix, rm is the
> complement of cp.

When in a working copy:

"svn rm" and then "svn commit" is the complement of "svn cp" and then
"svn commit".

Using "svn rm" or "svn cp" or "svn add" or any of several other
commands on a working copy merely schedules those operations to occur
at the next commit. If you change your mind and decide you don't want
to do those operations, you need to "svn revert" the file on which
you performed the operation that you want to unschedule.

--force should not be used unless you know what you're doing. In my
day-to-day Subversion use over the past 18 months, the use of --force
has only been necessary in one specific circumstance regarding
externals, which you're not using here.

> Maybe it's just a documentation/error message issue, but surely the
> cause of an inconsistent state is a bug?

I can't comment on that.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 1 14:23:13 2006

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

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