[Needs a test case.  Not sure I have a strong opinion one way or the
other about fixing it in a way similar to this (he is right that this
is a bit kludgey, but I'm not sure it is horribly so).

As far as I know (remember), nothing has changed between CVS 1.8 and
now (May 1998) which would affect this.

-kingdon]

Date: Sun, 16 Feb 1997 16:14:58 -0800 (PST)
From: Paul Traina <pst@Shockwave.COM>
To: bug-cvs@prep.ai.mit.edu


>Submitter-Id:   net
>Originator: 	 Paul Traina
>Organization:	 net
>Confidential:  no
>Synopsis:	export command fails for remotecvs
>Severity:	non-critical
>Priority:	medium
>Category: 	cvs
>Class:		sw-bug
>Release:	cvs-1.8.1
>Environment:

System: FreeBSD precipice.shockwave.com 3.0-CURRENT FreeBSD 3.0-CURRENT #1: Tue Feb 11 02:44:36 PST 1997 pst@precipice.shockwave.com:/a/src/sys/compile/PRECIPICE i386

This problem appears to be in 1.9 also.

>Description:

cvs -d server:/cvs-path export -Dfoo
fails with:
[export aborted]: cannot write <CVS/Template file>: No such file or directory

while the similar export command, done over NFS, works just fine.

>How-To-Repeat:

try to export a module using remote cvs, it will always fail

>Fix:

The CVS server is sending down a Template line during an export operation.
The real bug is that a Template should not be sent down for an export,
however, kludgey fixs for similar problems were done in client.c where
client.c checks the cvs command for "export" and merely refuses to
perform the operation when it sees the Template command from the server.

the kludgy -->UNTESTED<-- fix is:

In client.c, change the body of handle_template to read:

    if (strcmp (command_name, "export") != 0)
    {
      call_in_directory (pathname, template, NULL);
    }

This is a fine bandage for the problem until all the other export kludges
are fixed in server.c