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

Re: How Subversion drove me to shoot myself in the foot.

From: Fabian Cenedese <Cenedese_at_indel.ch>
Date: 2006-04-19 10:44:42 CEST

At 13:27 18.04.2006 -0400, Scott Palmer wrote:
>On 18-Apr-06, at 12:50 PM, Kevin Galligan wrote:
>>I think the contention was that 'svn delete' would not delete the actual files from the directory...
>>
>>"the book reassured me quite nicely that "svn delete" never actually deletes anything"
>>
>>which is, of course, not true...
>>
>>"Items specified by PATH are scheduled for deletion upon the next commit. *Files (and directories that have not been committed) are immediately removed from the working copy.* The command will not remove any unversioned or modified items; use the --force switch to override this behavior."
>
>Does anyone else think that the strategy of immediately removing (deleting) files that are added but not committed is not consistent with the idea that svn delete will not remove unversioned or modified items?

I also ran into this. If you look in the mail archives you'll find more people
having had that problem. I recall 2 or 3 alone in the last few weeks.

>I think it makes more sense for "svn delete" to behave like "svn revert" in the case of added but not committed files, because obviously it is an operation that WILL lose unversioned data.

Either that or the mentioned warning to use svn revert instead. My preferred
way would be the cvs-way to only delete files if given a flag. Like that it's
sure that the user wants to delete the file locally.

bye Fabi

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 19 10:46:10 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.