Pavel Roskin writes:
>
> ** expected:
> U realmodule/a
> cvs [a-z]*: Executing ../tmp/cvs-sanity/cvsroot/checkout\.sh. .realmodule..
> checkout script invoked in .*
> args: realmodule
> ** got:
> U realmodule/a
> checkout script invoked in /tmp/cvs-serv13285
> args: realmodule
> cvs server: Executing ''/tmp/cvs-sanity/cvsroot/checkout.sh' 'realmodule''
> FAIL: modules5-8
>
> It seems to be a trivial problem with sorting the output. However, this
> makes me wonder if "make remotecheck" is a part of the release procedure.
Yes, it is. There is a race condition that occasionally causes out-of-
order output from a few of the modules tests. If you re-run the test,
it will likely work fine. I don't want to sort the output, because you
really want to get the message that CVS is running the script before you
see any output from the script. Unfortunately, I haven't figured out a
reliable way to avoid the race yet.
> Maybe "make check" should include the remote testing? The later should
> exit gracefully (i.e. with code 0) if the binary doesn't include server
> support (now it fails).
No, there's "make remotecheck" to run the remote tests.
-Larry Jones
These findings suggest a logical course of action. -- Calvin
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
