Hi, On 2011-06-10 22:57:00 +0000, Thorsten Glaser wrote: > as you can see, this behaviour is consistent across all commands: > > add.c: error (0, 0, "nothing known about `%s'", finfo.fullname); > admin.c: error (0, 0, "nothing known about %s", finfo->file); > classify.c: error (0, 0, "nothing known about `%s'", > commit.c: error (0, 0, "nothing known about `%s'", finfo->fullname); > commit.c: error (0, 0, "nothing known about `%s'", finfo->fullname); > commit.c: error (0, 0, "nothing known about `%s'", finfo->fullname); > log.c: error (0, 0, "nothing known about %s", finfo->file); > remove.c: error (0, 0, "nothing known about `%s'", finfo->fullname); > tag.c: error (0, 0, "nothing known about %s", finfo->file);
No, it is not consistent: ypig:~/web-arenaire> cvs update foo Password: cvs update: nothing known about foo ypig:~/web-arenaire> cvs log foo Password: cvs log: nothing known about foo zsh: exit 1 cvs log foo Now, I'm now thinking that this inconsistency may be normal, because "cvs update" can make files appear or disappear in the working copy; so, the non-existence of the file may be regarded as a possible status of the directory. Similarly, "cvs status" returns with a 0 exit status, but it outputs the expected information on non-existing files, so that I'd say this is correct too, e.g.: cvs status: nothing known about foo =================================================================== File: no file foo Status: Unknown Working revision: No entry for foo Repository revision: No revision control file cvs always returns an error, when CVSROOT is not specified, though, but this is normal. > I could change it, but I fear I’d break things in scripts, > especially that Debian pushes the much-loathed 'set -e'. > Have you considered asking upstream about the reasons? > AFAIR the svn developers are former cvs developers. In 2005, svn also had various inconsistencies. They have been fixed for "svn rm" and "svn info", but "svn status" and "svn update" still return a 0 exit status. I think this is normal in a working copy (for instance, "svn st <file>" makes sense as <file> may be in base and has been removed with "rm" by the user). But I doubt the 0 exit status is correct when not in a working copy. I've just posted a message about that in the users Subversion list. Now, I think this cvs bug can be closed. -- Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
