[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Weird module behavior
From: |
Teala Spitzbarth |
Subject: |
RE: Weird module behavior |
Date: |
Fri, 14 Sep 2001 15:59:55 -0700 |
Robert,
I don't have any answers, but I can
say that I have seen similar behavior.
For awhile I was using an aliased module
that excluded certain directories -
but found that our developers (using pserver
connections), would land up getting the
excluded directories when they attempted
to update that module on their working copies.
I reorganized the structure of the tree to avoid it -
i.e. moved the exluded directories up a level in
the repository filesystem.
We are running 1.10.8 on a RH6.2 system with
pserver connections from RH6.2, WinCVS1.06, & Solaris 8.
Thanks,
Teala
-----Original Message-----
From: Robert Kerr [mailto:address@hidden
Sent: Friday, September 14, 2001 2:10 PM
To: address@hidden
Subject: Weird module behavior
Hi all,
I have a strange problem with cvs, and I'm hoping I can get some
guidance
from the list.
I have a repository on a machine (call it dumbo). I have a major
project
in it--call it gipper.
Gipper has some subdirectories in it (suba and subb).
I've set up the modules file so that we can do a cvs checkout on gipper,
and get all the files in the main gipper directory along with the suba
and
subb directories. Now there's been a request to make a module that just
checks out suba and subb by themselves, plus the makefile from the main
directory. Okay, so I've set up a module (call it freddy), that checks
out the makefile, suba and subb and puts them in a directory called
freddy. So far, so good.
Now comes the fun stuff.
On dumbo, if I do an update in the freddy directory, cvs looks at the
makefile, and the two subdirectories and that's it. But if I'm doing
this
remotely, when I do an update in freddy, it looks at the subdirectories
and the makefile, and then proceeds to add in the other files from the
main directory, which I don't want.
I thought it was a problem with versions (dumbo is running 1.11, whereas
my remote computer is running 1.10.8). So I downloaded and compiled
1.11.p1 for my remote computer, but it still exhibits the same behavior.
Now, on a different remote computer it actually does the update
correctly.
Does anyone have any ideas what is happening?
--
-bob