[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cvs checkout problem (Update to previous msgs and hopefully clarificatio

From: Terry Spafford
Subject: cvs checkout problem (Update to previous msgs and hopefully clarifications)
Date: Thu, 21 Feb 2002 11:18:43 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]