cvs checkout problem (Update to previous msgs and hopefully clarifications)

[Terry Spafford]

Thank you to everyone one who's tried to help me out a bit; you've given 
me a few ideas, though in the end I suspect I'll probably end up staying 
  with the method I've come up with mainly because the mangement is 
anxious for me to wrap up this side project.

First, my biggest problem, that seems to occur regardless of how the 
tree is set up.

All my original tests and scripts I developed were done with a cvs tree 
on my local machine. That worked fine. My local machine is running Red 
Hat 7.1 with the version of CVS that came with it. (cvs -v reports 
1.11). The machine that the repository is going to reside on is running 
a similar setup including cvs version.

When the cvs tree is local, I can specify the directory to check out 
into with the command
         cvs co -d (new_dir) (codetree)


Once the tree was moved to the remote machine though, I get problems.
I can check out the code no problem using the command:
         cvs co (codetree)

But when I try to specify the directory using:
         cvs co -d (new_dir_local_machine) (codetree)

I get the following error:
cvs [server aborted]: absolute pathname `/home/tspaffor/temp/aftn' 
illegal for server

I can rlogin into the repository machine no problem. One thing that 
might be an issue is that my local machine and the repository machine 
are on separate networks we have in the building. (My machine is on the 
general use network, while the vault is on the development machine 
network, even though like most devers here, we use our general use 
machines for development work. :)

Update (since I don't want to delete what I just typed out. :)

I just tried to use a local directory instead of absolute directories 
and that does seem to work. It's a bit of a cludge but once I tweek the 
scripts a bit it will work. Does anyone have any other ideas for making 
this work with an absolute path name?

As for the other comments people have made , I first want to say thank 
you for trying to make sense of my ramblings. :>

Due to the fact that I'm getting pressure to move on to other stuff from 
above now, I'll probably end up sticking with the method I've developed, 
though I am realizing that I did dismiss using Modules a bit too quickly 
and that they would probably have helped my organization a hell of a lot 
more; At some point while we're still going through the growing pains of 
this change over I may even be able to slip in a method using them too. :)

Sadly, the way we ported our Unix code over to Linux, along with the 
fact that we simply do not have the manpower nor time to spare to port 
back means there is no way we can merge the UNIX and Linux versions of 
our code back together any time soon.

Due to the nature of our customers and the fact that once a system gets 
up and running on the customer site we rarely have easy access to it any 
more, we have given up trying to keep code in synch between customers, 
or with customers and new development. Most of the time, the only 
changes we get to do for a system once it is installed is a bug fix the 
customer requests. Since we only have about 20 customers or so (give or 
take 10) at any one time, and since our product at the moment is 
actually quite stable (due to 20-some years of development), this hasn't 
been too much of a problem so far. (I know it'll bite us in our butts 
eventually though. :)

As for why we want to specify directories where code goes, it is because 
we have many more customers then we have Alpha's to work on, so Unix 
boxes will often be set up to be more then one customer at a time 
depending on which binaries are running. In other words, Dever1 needs to 
be able to be working on Cust2's code on the same Alpha that Dever2 is 
working on a bug fix for Cust3. As I'm typing this now, one of our 
Alpha's currently has code for at least 3 Customer's right now, not all 
running at the same time of course, but all being worked on/developed at 
the same time on the same machine.

Thank you for your time, and your patiance.

--
Terry Spafford
Software Engineer
Global Weather Dynamics Inc
Monterey, California, USA
address@hidden
www.gwdi.com