Hi All,
While getting code from CVS Server (Suse Linux Enterprise Edition
7.0) using wincvs I am getting the following error
cvs server: module `QPS/ALLPRODS_CDFJM' in modules file contains infinite
loop
cvs server: cannot open current directory: Too many open files
cvs [checkout
Hi,
In CVS, is it possible to restrict the rights create a tag only to
certain users?
If it is possible, please guide me as to how can this be done?
Thanks and Regards,
Nitin Dube
___
Info-cvs mailing list
[EMAIL PROTECTED]
Amit,
Please do post your modules file, state cvs versions used (client and
server) and have a glance at your project structure...
This all will help pinpoint the right answer.
(Best guess for now, is that your modules file contains looped references...
*grin*)
Cheerio,
Guus
Thanks, I know now why:
because at the end of verifymsg I added a line like this:
DEFAULT /usr/local/src/cvssupport/logmsg.verify
as asked for configuring CVSZilla.
by the way Idid launch CVSZilla.
Now i am trying to understand how it works ,but there is no help anywhere.
I don't know why the
Hi
I have a problem with the new version 1.11.5 with modules. I could checkout
the modules file with chekout -c but that doesn't seem to work anymore. If I
replace it with 1.11.1p1 it works again. I don't have the interim releases.
cvs.exe -t -d P:\Z_K\Pec3000cvs2 checkout -c
- main loop with
Fabian Cenedese writes:
I have a problem with the new version 1.11.5 with modules. I could checkout
the modules file with chekout -c but that doesn't seem to work anymore.
Yep, it's a bug that's already fixed in the current development version.
-Larry Jones
From now on, I'm devoting myself
Hi,
I am trying to write a generic script that we will be able run from any host
on our network, including possibly the server hosting the cvs pserver and I
am running into a problem.
When I run the following command on a client computer it works as expected:
cvs -d :pserver:[EMAIL
Dan,
I have been creating a post tag trigger for CVS. I'm very close to
finishing and I will post a patch to the info-cvs list.
On 02/24/03 10:28:19, Dan Peterson wrote:
A user has asked the following question (see below). I don't believe
there's a way to do what he wants, but thought I'd
Craig Dickson writes:
When I run the following command on a client computer it works as expected:
cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot checkout -d . test
Running CVS as root is nuts. Doing it using pserver doubly so.
However, when I run it on the box that is actually
When I run the following command on a client computer it works as
expected:
cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot checkout -d . test
Running CVS as root is nuts. Doing it using pserver doubly so.
Its just a test system, so get over it.
However, when I run it on the
Craig Dickson wrote:
When I run the following command on a client computer it works as
expected:
cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot checkout -d . test
Running CVS as root is nuts. Doing it using pserver doubly so.
Its just a test system, so get over it.
[EMAIL PROTECTED] (Larry Jones) writes:
[EMAIL PROTECTED] writes:
Client: WinCVS 1.3.12 on Windows NT 4.0 SP6a
Server: cvs 1.11.2 on AIX 4.3.3
Communication Method: pserver
The first thing to do is to upgrade your server to the current release
of CVS (1.11.5) and see if that fixes the
[EMAIL PROTECTED] writes:
I have now completed the upgrade. Same result - big core dumps in /tmp.
Can you get a traceback from one of the dumps?
-Larry Jones
Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin
___
Info-cvs
I changed the entry in /etc/inetd.conf to add -t to the cvs command line,
but I don't seem to be able to find any trace output anywhere. Where would
it have been written to?
Mark Chojnacki
[EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
I changed the entry in /etc/inetd.conf to add -t to the cvs command line,
but I don't seem to be able to find any trace output anywhere. Where would
it have been written to?
Trace output goes to stderr, which for a server is probably nowhere,
but it doesn't matter
-Original Message-
From: Todd Denniston [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 1:08 PM
To: Craig Dickson
Cc: [EMAIL PROTECTED]
Subject: Re: Checkout problem on cvs host
Craig Dickson wrote:
When I run the following command on a client computer
OK. Here's what I get from dbx:
$ dbx /usr/local/bin/cvs core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]
Segmentation fault in expand_catname at 0xd01895b0 ($t1)
0xd01895b0 (expand_catname+0x18) 9421f780 stwu r1,-2176(r1)
(dbx)
Mark Chojnacki
After further investigation, I actually am now seeing it on the client box
as well. Perhaps I was all along ...
Here is the terminal output:
C:\dev\test\MAINcvs checkout -d . test
cvs server: existing repository /usr/local/cvsroot does not match
/usr/local/cvsroot/test
cvs server: ignoring
Craig Dickson wrote:
After further investigation, I actually am now seeing it on the client box
as well. Perhaps I was all along ...
Here is the terminal output:
C:\dev\test\MAINcvs checkout -d . test
cvs server: existing repository /usr/local/cvsroot does not match
Hi Chris,
I don't know 'pure' cvs solution but I think you can use such a trick:
cvs -Q rdiff -s -r TAG1 -r TAG2 module_name|awk '{print $2}'|xargs cvs co
where module_name could be a directory name also.
Step by step desc.:
cvs -Q rdiff -s -r TAG1 -r TAG2 module_name
generate a list of changed
20 matches
Mail list logo
