Jean-Luc Herren <jlh@xxxxxx> writes:
> Note that if cvs misses the server subcommand, it will spit out
> the list of available commands to stderr, which is not useful in
> this situation. It seemed to me that redirecting stderr to
> /dev/null is a bad idea, as cvs (when it works properly) might
> potentially print out useful informations to stderr. Maybe
> someone has an idea about how to eliminate the help message
> properly.
> ...
> @@ -340,7 +343,11 @@ sub conn {
> $self->{'socketo'}->write("valid-requests\n");
> $self->{'socketo'}->flush();
>
> - chomp(my $rep=$self->readline());
> + my $rep=$self->readline();
> + if (!defined $rep) {
> + die $ownserver ? "'cvs server' failed; make sure you have a cvs with server support" : "Remote end hung up unexpectedly";
> + }
> + chomp $rep;
I guess this is probably the best we can do without bending
backwards too much.
If we do not have cvs with server support, is there a fallback
method we can still use to run cvsps?
> diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
> index 7706430..d8cbfd0 100755
> --- a/t/t9600-cvsimport.sh
> +++ b/t/t9600-cvsimport.sh
> @@ -10,6 +10,13 @@ then
> exit
> fi
>
> +if echo -n | cvs server 2>&1 | grep 'Unknown command' > /dev/null
> +then
> + say 'skipping cvsimport tests, cvs has support for server mode'
> + test_done
> + exit
> +fi
Do you mean "has to support server" or "does not have support for"?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
