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

Re: [PATCH]#2440 svn rm nonexistent exits with success

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-12-13 15:50:35 CET

kfogel@collab.net wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>1. Do we really want this to throw an error? People may have scripts
>>that rely on it succeeding.
>
> True, though in general we've taken the attitude that it's okay to
> break scripts that depend on a buggy behavior (unless it would cause
> dataloss in some obvious way, of course).

Yes - if we decide that silently accepting a delete of a non-existent item was
a bug, then we can fix it.

>>2. Where are we going to write down our policy on whether a command
>>like this should throw an error or a warning? It's obvious that we
>>need to, since the question crops up over and over again.
>
> (Note: whatever we consense on will go into hacking.html, of course.)

I'm sure there's a better place to define the user interface to the
command-line client, but that'll do for now.

> Here's a policy proposal:
>
> "A Subversion command should, by default, error when asked to do
> something that it cannot do (e.g., remove a non-existent file).
> Here, "error" means both display a message on stderr and return
> non-success. However, it is acceptable for some commands to not
> error in this circumstance, iff passed the '--force' flag. This
> is a convenience for scripts that don't need to bother with
> sophisticated error handling."
>
> Thoughts?

That seems contrary to what I recall as many recent changes in favour of
skipping over a non-existent target with a warning.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 13 15:53:59 2005

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.