Re: exit codes and locking

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
Received on Fri Apr 8 19:28:29 2005