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
[EMAIL PROTECTED]
www.gwdi.com
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
