You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jim Correia <ji...@pobox.com> on 2005/04/08 16:09:53 UTC
exit codes and locking
Is (our should) subversion be consistent about returning non-zero exit
codes when an operation failed?
If I attempt to do a commit in a working copy of a file locked in
another working copy, the commit fails with an error message, and the
exit code is 1.
If I attempt to unlock a file which is locked in another working copy,
without --force, it fails with an error message and the exit code is 1.
However, if I attempt to lock a file that is locked in another working
copy, it fails with an error message, but the exit code is 0.
This is using the 1.2rc1 tarball.
===
I picked rm as another random operation to try:
correia$ svn rm someFileThatDoesNotExist
correia$ echo $?
0
Is that as it should be, or should it complain that the file doesn't
exist?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: exit codes and locking
Posted by Jim Correia <ji...@pobox.com>.
On Apr 8, 2005, at 4:20 PM, Peter N. Lundblad wrote:
> On Fri, 8 Apr 2005, Julian Foad wrote:
>
>> Jim Correia wrote:
>>> Is (our should) subversion be consistent about returning non-zero
>>> exit
>>> codes when an operation failed?
>>
>> Yes, absolutely it should, and I believe it is pretty consistent. Any
>> deviation is a bug.
>>
> ...
>>> However, if I attempt to lock a file that is locked in another
>>> working
>>> copy, it fails with an error message, but the exit code is 0.
>>
>> Bug. Thanks for reporting it.
>>
> What should we return if some locks are successfully acquired and some
> not? The reason this happens is because it is handle by the
> notification
> system. I think the same happens for a failed revert, but I haven't
> tested. Don't we have other commands that will just print an error
> message
> and continue?
svn revert fileThatDoesNotExist
reports:
Skipped 'fileThatDoesNotExist'
and returns 0.
If that is the expected behavior (and eventually becomes documented to
be so) that's ok by me. I just wanted to make sure that was the
expected behavior in this case.
(The rm case seems worse because it silently succeeds - if it printed a
warning that would be better - issue filed.)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: exit codes and locking
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 8 Apr 2005, Julian Foad wrote:
> Jim Correia wrote:
> > Is (our should) subversion be consistent about returning non-zero exit
> > codes when an operation failed?
>
> Yes, absolutely it should, and I believe it is pretty consistent. Any
> deviation is a bug.
>
...
> > However, if I attempt to lock a file that is locked in another working
> > copy, it fails with an error message, but the exit code is 0.
>
> Bug. Thanks for reporting it.
>
What should we return if some locks are successfully acquired and some
not? The reason this happens is because it is handle by the notification
system. I think the same happens for a failed revert, but I haven't
tested. Don't we have other commands that will just print an error message
and continue?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: exit codes and locking
Posted by Jim Correia <ji...@pobox.com>.
On Apr 8, 2005, at 2:41 PM, Julian Foad wrote:
> It would be best if you could wait a day or so first, to see if anyone
> refutes this or is likely to fix this quickly. (They might, as the
> locking code is fresh in some people's minds.) But if there is no
> such response, or if you can't conveniently wait, yes please file an
> issue.
I can hang fire for a couple of days.
>>> Hmm... svn is not very good at responding to files that do not exist
>>> (neither on disk nor in version control) - it tends to ignore them
>>> as if you hadn't mentioned them. I think that's what's happening
>>> here ("OK, I've removed any files you asked me to - which wasn't any
>>> at all"). Likewise "svn up foo" and "svn st foo" silently succeed
>>> even if "foo" is nonexistent and unknown. I regard those all as
>>> bugs. I don't know if they are all filed in the issue tracker.
>> Should I file a bug against the rm case in the issue tracker, or not?
>
> Yes, please. But don't assume that the resolution will necessarily be
> that the operation should fail. There was recently a very similar
> comment on the behaviour of "propdel" silently succeeding on a
> non-existent property, and the same three options apply:
>
> 1. Silently skip the item (as we do now), and continue successfully.
> Document the behaviour as intentional. Currently:
> svn rm
> svn status
> svn update
>
> 2. Print a warning, skip the item, and continue successfully.
> Currently:
> svn revert
>
> 3. Print an error and fail immediately. Currently:
> all other commands
Understood. Clarification may be all that is needed for the fix, but
IMO 2 would be the most user friendly.
<http://subversion.tigris.org/issues/show_bug.cgi?id=2269>
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: exit codes and locking
Posted by Julian Foad <ju...@btopenworld.com>.
Jim Correia wrote:
> On Apr 8, 2005, at 1:27 PM, Julian Foad wrote:
>>> However, if I attempt to lock a file that is locked in another
>>> working copy, it fails with an error message, but the exit code is 0.
>>
>> Bug. Thanks for reporting it.
On second thoughts, I wonder if this was intentional?
> Should I file it in the issue tracker?
It would be best if you could wait a day or so first, to see if anyone refutes
this or is likely to fix this quickly. (They might, as the locking code is
fresh in some people's minds.) But if there is no such response, or if you
can't conveniently wait, yes please file an issue.
>>> This is using the 1.2rc1 tarball.
>>> ===
>>> I picked rm as another random operation to try:
>>> correia$ svn rm someFileThatDoesNotExist
>>> correia$ echo $?
>>> 0
>>> Is that as it should be, or should it complain that the file doesn't
>>> exist?
>>
>> Hmm... svn is not very good at responding to files that do not exist
>> (neither on disk nor in version control) - it tends to ignore them as
>> if you hadn't mentioned them. I think that's what's happening here
>> ("OK, I've removed any files you asked me to - which wasn't any at
>> all"). Likewise "svn up foo" and "svn st foo" silently succeed even
>> if "foo" is nonexistent and unknown. I regard those all as bugs. I
>> don't know if they are all filed in the issue tracker.
>
> Should I file a bug against the rm case in the issue tracker, or not?
Yes, please. But don't assume that the resolution will necessarily be that the
operation should fail. There was recently a very similar comment on the
behaviour of "propdel" silently succeeding on a non-existent property, and the
same three options apply:
1. Silently skip the item (as we do now), and continue successfully. Document
the behaviour as intentional. Currently:
svn rm
svn status
svn update
2. Print a warning, skip the item, and continue successfully. Currently:
svn revert
3. Print an error and fail immediately. Currently:
all other commands
Although (3) is only changing undocumented behaviour in the presence of invalid
inputs, it could be argued to be an incompatible change in behaviour.
> What happens if I do
>
> svn rm foo bar
>
> and foo exists, but bar does not? What should it return in that case? :-)
Case 3: failure. Cases 1 and 2: success.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: exit codes and locking
Posted by Jim Correia <ji...@pobox.com>.
On Apr 8, 2005, at 1:27 PM, Julian Foad wrote:
>> However, if I attempt to lock a file that is locked in another
>> working copy, it fails with an error message, but the exit code is 0.
>
> Bug. Thanks for reporting it.
Should I file it in the issue tracker?
>> This is using the 1.2rc1 tarball.
>> ===
>> I picked rm as another random operation to try:
>> correia$ svn rm someFileThatDoesNotExist
>> correia$ echo $?
>> 0
>> Is that as it should be, or should it complain that the file doesn't
>> exist?
>
> Hmm... svn is not very good at responding to files that do not exist
> (neither on disk nor in version control) - it tends to ignore them as
> if you hadn't mentioned them. I think that's what's happening here
> ("OK, I've removed any files you asked me to - which wasn't any at
> all"). Likewise "svn up foo" and "svn st foo" silently succeed even
> if "foo" is nonexistent and unknown. I regard those all as bugs. I
> don't know if they are all filed in the issue tracker.
Should I file a bug against the rm case in the issue tracker, or not?
What happens if I do
svn rm foo bar
and foo exists, but bar does not? What should it return in that case?
:-)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: exit codes and locking
Posted by Julian Foad <ju...@btopenworld.com>.
Jim Correia wrote:
> Is (our should) subversion be consistent about returning non-zero exit
> codes when an operation failed?
Yes, absolutely it should, and I believe it is pretty consistent. Any
deviation is a bug.
> If I attempt to do a commit in a working copy of a file locked in
> another working copy, the commit fails with an error message, and the
> exit code is 1.
Good.
> If I attempt to unlock a file which is locked in another working copy,
> without --force, it fails with an error message and the exit code is 1.
Good.
> However, if I attempt to lock a file that is locked in another working
> copy, it fails with an error message, but the exit code is 0.
Bug. Thanks for reporting it.
> This is using the 1.2rc1 tarball.
>
> ===
>
> I picked rm as another random operation to try:
>
> correia$ svn rm someFileThatDoesNotExist
> correia$ echo $?
> 0
> Is that as it should be, or should it complain that the file doesn't exist?
Hmm... svn is not very good at responding to files that do not exist (neither
on disk nor in version control) - it tends to ignore them as if you hadn't
mentioned them. I think that's what's happening here ("OK, I've removed any
files you asked me to - which wasn't any at all"). Likewise "svn up foo" and
"svn st foo" silently succeed even if "foo" is nonexistent and unknown. I
regard those all as bugs. I don't know if they are all filed in the issue tracker.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org