(no subject)
A simple question.Can I discover on which branch a file is being committed from withina script run from the commitinfo file?Basically, I know how to apply per user/module access controls, but I would like to extend this to include branch information so that certain teams are confinedto branches. We have in the past experienced code fixes being applied to thewrong branch and it would be preferable for the technology to help people avoidthat mistake in the future.#!/mjhú ¾ÉX§X¬´ß¡Ëì{¨®m¶ÿ¨¥{¨®æj)fjåËbú?wèrû
Re: (no subject)
hi, cvs doesnt pass branch information to commitinfo file, so you cant use commitinfo for that. I had the same problem, and then solved with writing a patch for access control. Available at http://www.geocities.com/barissahin/ baris --- [EMAIL PROTECTED] wrote: A simple question.Can I discover on which branch a file is being committed from withina script run from the commitinfo file?Basically, I know how to apply per user/module access controls, but I would like to extend this to include branch information so that certain teams are confinedto branches. We have in the past experienced code fixes being applied to thewrong branch and it would be preferable for the technology to help people avoidthat mistake in the future.#!/mjh"wèrû)b b²Ò'~/² !¶Úþf¢ ?¨¥©ÿ+-wèþ)ß¡Ëì Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes
Re: (no subject)
I'd come to that belief too, but I was hoping otherwise!Thanks for the URL - I'll see where that gets me.#!/mjh-Baris Sahin [EMAIL PROTECTED] wrote: -To: [EMAIL PROTECTED]From: Baris Sahin [EMAIL PROTECTED]Date: 09/03/2002 12:05PMcc: [EMAIL PROTECTED]Subject: Re: (no subject)hi,cvs doesnt pass branch information to commitinfo file,so you cant use commitinfo for that.I had the same problem, and then solved with writing a patch for access control. Available at http://www.geocities.com/barissahin/baris--- [EMAIL PROTECTED] wrote:A simple question.Can I discover on which branch a file is being committed from withina script run from the commitinfo file?Basically, I know how to apply per user/module access controls, but I would like to extend this to include branch information so that certain teams are confinedto branches. We have in the past experienced code fixes being applied to thewrong branch and it would be preferable for the technology to help people avoidthat mistake in the future.#!/mjh"wèrûj)bb²Ò'~/²î¢¸!¶Úþf¢î¢¸?¨¥©ÿ+-wèþ)ß¡ËìDo You Yahoo!?Yahoo! Finance - Get real-time stock quotesú ¾ÉX§X¬´ß¡Ëì{¨®m¶ÿ¨¥{¨®æj)fjåËbú?wèrû
CVS behaviour on different platforms
Good morning I would like to ask you for discussion on the following problem: CVS login: I need to run a CVS command: On windows I type the following: C:\cvs -d :pserver:olibsup:rams01@mucobet4:/ama/scm/repository/scmtest checkout . Works fine. From another UNIX box I type the same command and I receive: $cvs -d :pserver:olibsup:rams01@mucobet4:/ama/scm/repository/scmtest checkout . Fatal error, aborting. olibsup:rams01: no such user cvs log: used empty password; try cvs login with a real password Why the same release (version) of CVS behaves in different way on UNIX and Windows? CVS version: 1.11 (Windows-client, UNIX-client/server) Best regards Pawelek __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: lock failed - giving up
Hi everyone, I'm trying to commit files into the repository and here is the error message I get: /#cvs.lock): No such file or directoryctory for `/home/my/cvs/repository cvs commit: lock failed - giving up cvs [commit aborted]: lock failed - giving up I have previously locked the two files I tried to commit, but even after I release the lock I still get the same error message. Any help would be greatly appreciated. Thanks! James McMurray (817) 234-6817 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: lock failed - giving up
McMurray, James writes: /#cvs.lock): No such file or directoryctory for `/home/my/cvs/repository cvs commit: lock failed - giving up cvs [commit aborted]: lock failed - giving up That error message is garbled -- my guess is that you have LockDir= in your CVSROOT/config file and it's got a stray CR at the end of the line. -Larry Jones I think your train of thought is a runaway. -- Calvin's Mom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs [commit aborted]: lock failed - giving up
There is no LockDir= in the config file. In fact, the config file is still the default one that was created at install. James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 03, 2002 10:29 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: cvs [commit aborted]: lock failed - giving up McMurray, James writes: /#cvs.lock): No such file or directoryctory for `/home/my/cvs/repository cvs commit: lock failed - giving up cvs [commit aborted]: lock failed - giving up That error message is garbled -- my guess is that you have LockDir= in your CVSROOT/config file and it's got a stray CR at the end of the line. -Larry Jones I think your train of thought is a runaway. -- Calvin's Mom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: lock failed - giving up
McMurray, James writes: There is no LockDir= in the config file. In fact, the config file is still the default one that was created at install. In that case, my second guess is that you're trying to share a working directory between DOS/Windows and Unix, which is a no-no due to the different line-ending conventions. The immediate problem is probably due to the CVS/Root file having a CR at the end of the line which confuses Unix since it thinks it's part of the path rather than part of the line ending, but you'll have similar problems will all your files. You need to have separate working directories for different systems. -Larry Jones There's never enough time to do all the nothing you want. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs [commit aborted]: lock failed - giving up
I do currently have a Windows 2000 client and Linux server setup. Is there a way to implement this? We are using Samba to communicate between the two, if that helps. Thanks, James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 03, 2002 10:55 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: cvs [commit aborted]: lock failed - giving up McMurray, James writes: There is no LockDir= in the config file. In fact, the config file is still the default one that was created at install. In that case, my second guess is that you're trying to share a working directory between DOS/Windows and Unix, which is a no-no due to the different line-ending conventions. The immediate problem is probably due to the CVS/Root file having a CR at the end of the line which confuses Unix since it thinks it's part of the path rather than part of the line ending, but you'll have similar problems will all your files. You need to have separate working directories for different systems. -Larry Jones There's never enough time to do all the nothing you want. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: lock failed - giving up
McMurray, James writes: I do currently have a Windows 2000 client and Linux server setup. Is there a way to implement this? Of course, that's what lots of people do! We are using Samba to communicate between the two, if that helps. No, it doesn't; in fact, it's almost certainly the root of your problems. I'd suggest getting rid of it entirely. What you need to do is to set up client/server CVS. See the CVS manual for details: http://www.cvshome.org/docs/manual/cvs_2.html#SEC26 -Larry Jones It's no fun to play games with a poor sport. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: (no subject)
From: Baris Sahin [EMAIL PROTECTED]
Subject: Re: (no subject)
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Date: Tue, 3 Sep 2002 04:05:26 -0700 (PDT)
hi,cvs doesnt pass branch information to commitinfo file,so you cant
use commitinfo for that.I had the same problem, and then solved with
writing a patch for access control. Available at
http://www.geocities.com/barissahin/
While it is true that the commitinfo script is not given any explicit
arguments about the branch, this does not mean that you can not find out
this information.
The commitinfo script is running in a directory where the files given on
the command line reside as local files. There is also a copy of the CVS
directory present and the CVS/Entries file contains the branch information
if you want to parse it. There are two ways you could get that information.
You may either write a script to 'manually' parse the CVS/Entries file
something like the following perl script fragment:
open(ENTRIES, $ENTRIES) || die(Cannot open $ENTRIES.\n);
while (ENTRIES) {
chomp;
# /file/ver/timestamp/options/tag_or_date
my($filename, $version,$ts,$opt,$tag) = split('/', substr($_, 1));
$cvsversion{$filename} = $version;
# the /^D/ date specification for a tag should not be possible in a commit
# so ignore it
if ($tag eq '' || $tag =~ /^T/) {
$cvsbranch{$filename} = $tag;
}
$cvsoption{$filename} = $opt;
}
close(ENTRIES);
It should also be possible to do something like:
cvs -Qn status filename
and parse the 'Sticky Tag:' line in your script.
This does not require any patches to cvs at all.
-- Mark
baris
--- [EMAIL PROTECTED] wrote:
-
A simple question. Can I discover on which branch a file is being
committed from withina script run from the commitinfo file? Basically,
I know how to apply per user/module access controls, but I would like
to extend this to include branch information so that certain teams are
confinedto branches. We have in the past experienced code fixes being
applied to thewrong branch and it would be preferable for the
technology to help people avoidthat mistake in the future.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
Yes, you're right... you can use either of the two methods
mentioned, 'cvs status', or the Entries file. Still, both
of these methods are client side and their success depends
upon software (e.g. Perl) that may or may not be present on
client machines.
I've yet to see a good reason why a patch that passes the
branch tag can't be incorporated into, for example, commit.c
so the rules can be implemented completely on the server side.
Maybe there's more to it than I'm seeing?
-D
hi,cvs doesnt pass branch information to commitinfo file,so you cant
use commitinfo for that.I had the same problem, and then solved with
writing a patch for access control. Available at
http://www.geocities.com/barissahin/
While it is true that the commitinfo script is not given any explicit
arguments about the branch, this does not mean that you can
not find out
this information.
The commitinfo script is running in a directory where the
files given on
the command line reside as local files. There is also a copy
of the CVS
directory present and the CVS/Entries file contains the
branch information
if you want to parse it. There are two ways you could get
that information.
You may either write a script to 'manually' parse the CVS/Entries file
something like the following perl script fragment:
open(ENTRIES, $ENTRIES) || die(Cannot open $ENTRIES.\n);
while (ENTRIES) {
chomp;
# /file/ver/timestamp/options/tag_or_date
my($filename, $version,$ts,$opt,$tag) = split('/', substr($_, 1));
$cvsversion{$filename} = $version;
# the /^D/ date specification for a tag should not be
possible in a commit
# so ignore it
if ($tag eq '' || $tag =~ /^T/) {
$cvsbranch{$filename} = $tag;
}
$cvsoption{$filename} = $opt;
}
close(ENTRIES);
It should also be possible to do something like:
cvs -Qn status filename
and parse the 'Sticky Tag:' line in your script.
This does not require any patches to cvs at all.
-- Mark
baris
--- [EMAIL PROTECTED] wrote:
-
A simple question. Can I discover on which branch a file is being
committed from withina script run from the commitinfo file?
Basically,
I know how to apply per user/module access controls, but I would like
to extend this to include branch information so that certain
teams are
confinedto branches. We have in the past experienced code fixes being
applied to thewrong branch and it would be preferable for the
technology to help people avoidthat mistake in the future.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
At 01:06 PM 9/3/2002, Douglas Finkle wrote: Yes, you're right... you can use either of the two methods mentioned, 'cvs status', or the Entries file. Still, both of these methods are client side and their success depends upon software (e.g. Perl) that may or may not be present on client machines. The script named in commitinfo executes on the server side. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Strategy to merge an Rev A.a modification into Rev A, B, C ... sources
I have revisions A, B, and C (and D before long), of a released tarball package (CGI-perl source). I made some widely scattered (almost 30 files touched), but compact (almost always contained within a single-line) revisions to revision A (cleaning up the HTML output of the CGI-perl), and I want to merge them in to my copy of the evolving trunk ASAP, to minimze versionitis. I set up my own CVS repository on my linux box. I want to track A, B, C and future revisions to be able to diff the changes. This particular package's source doesn't change wildly between point releases. What I want to do is catch up a merge of my HTML changes to revision C as soon as possible, mark that merged version as the head, and forever after, merge in the changes to each revision against my modified copy. How can I best use CVS to manage this task? I'm starting from scratch, so I have no restrictions on how I set this up, I want to make it as amenable to automated tools as possible. I'm hoping that since all the changes I've been making were on single lines of HTML, that a patch tool can be used to either merge in the changes of the new revisions or bring my revisions out to the tarball releases going forward. Any suggestions, in as specific a detail as possible, would be greatly appreciated. Thanks. (P.S. If this is generally unworkable to 'catch up' to Rev C, I'll just redo my changes on that version before Rev D comes out, and start from there) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
At 01:06 PM 9/3/2002, Douglas Finkle wrote: Yes, you're right... you can use either of the two methods mentioned, 'cvs status', or the Entries file. Still, both of these methods are client side and their success depends upon software (e.g. Perl) that may or may not be present on client machines. The script named in commitinfo executes on the server side. Sure, but what about the data that the script looks at? On the server side of things there is no CVS/Entries file, and 'cvs status' will fail if there's no checked out sources. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: branch access control
Hi Douglas, From: Douglas Finkle [EMAIL PROTECTED] Date: Tue, 3 Sep 2002 13:06:15 -0400 Yes, you're right... you can use either of the two methods mentioned, 'cvs status', or the Entries file. Still, both of these methods are client side and their success depends upon software (e.g. Perl) that may or may not be present on client machines. You are either mistaken or you are running a modified cvs that is not based on the cvshome.org sources. The URL: http://www.cvshome.org/docs/manual/cvs_18.html#SEC167 says: |Note: when CVS is accessing a remote repository, `commitinfo' will | be run on the _remote_ (i.e., server) side, not the client side (*note | Remote repositories::). I've yet to see a good reason why a patch that passes the branch tag can't be incorporated into, for example, commit.c so the rules can be implemented completely on the server side. Putting a 'cvs -Qn status filename' into a commitinfo log loginfo script WILL run on the server side. It works today with versions of cvs going back at least as far as 1.10.5 (the oldest version I had on hand to test with for compatibility just now). Maybe there's more to it than I'm seeing? It seems likely this is true. Enjoy! -- Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
At 01:33 PM 9/3/2002, Douglas Finkle wrote: At 01:06 PM 9/3/2002, Douglas Finkle wrote: Yes, you're right... you can use either of the two methods mentioned, 'cvs status', or the Entries file. Still, both of these methods are client side and their success depends upon software (e.g. Perl) that may or may not be present on client machines. The script named in commitinfo executes on the server side. Sure, but what about the data that the script looks at? On the server side of things there is no CVS/Entries file, and 'cvs status' will fail if there's no checked out sources. Somebody said: The commitinfo script is running in a directory where the files given on the command line reside as local files. There is also a copy of the CVS directory present and the CVS/Entries file contains the branch information if you want to parse it. There are two ways you could get that information. I believe that is a true statement for both client/server and local modes. ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
$CVS_USER won't expand in loginfo...
Hi,
I'm using CVS v1.11 and i just can't seem to get the $CVS_USER environment
variable expanding in any of my *info files. I'm using pserver to connect
winCVS client to CVS on SunOS 5.8, and because not everybody has unix
accounts i have a cvs passwd file which looks something like:-
user1::cvsowner
user2::cvsowner
.
.
.
etc
where cvsowner is the unix user which actually runs CVS, and the user1,2,3
are peoples windows logons. I can get $USER to expand, but this of course
expands into 'cvsowner' as the server user, and not the actual CVS user who
performed the commit. I've tried all sotrs of forms ($CVS_USER,
$CVS_USERNAME, %CVS_USER_NAME, ${CVS_USER}, etc etc), and i always get the
same error reported back:cvs server: loginfo:27: no such internal variable
$CVS_USER. Scouring the web i can see this used to be a problem back in 98
and would have thought it was fixed by now!
In my loginfo file i only have a single line:-
^cgr_test /export/cvs/CVSROOT/loginfo.ksh $CVS_USER %{sVv}
I've also tried this just on the unix box (taking winCVS out of the
equation) and get the same result, and i tried using cvs v1.11.2 as well,
still with no results.
Can anyone help me access the real cvs user who performed an action in my
*info scripts please?
Thanks,
Chris
This e-mail and any attachment is for authorised use by the intended recipient(s)
only. It may contain proprietary material, confidential information and/or be subject
to legal privilege. It should not be copied, disclosed to, retained or used by, any
other party. If you are not an intended recipient then please promptly delete this
e-mail and any attachment and all copies and inform the sender. Thank you.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
[commit aborted] cannot rename file ,xxx, to file,v: file exists
Hello again everyone, hopefully I have nearly all of my problems ironed out. :-) I am trying to commit files on another PC and keep getting errors. It opens up the text editor just fine, and saves the comment. However, it then gives the following error: cvs.exe [commit aborted] cannot rename file ,filename, to filename,v: file exits. I have searched the archives and found several people asking this same question, but no responses to those questions. Is this a mystery issue that has no resolution? As always, your help is greatly appreciated. James McMurray (817) 234-6817 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strategy to merge an Rev A.a modification into Rev A, B, C ... sources
On Tue, Sep 03, 2002 at 01:28:05PM -0400, Jeff Kowalczyk wrote: I have revisions A, B, and C (and D before long), of a released tarball package (CGI-perl source). I made some widely scattered (almost 30 files touched), but compact (almost always contained within a single-line) revisions to revision A (cleaning up the HTML output of the CGI-perl), and I want to merge them in to my copy of the evolving trunk ASAP, to minimze versionitis. See http://www.cvshome.org/docs/manual/cvs_13.html#SEC104 . The short version is that you put your modifications on the trunk, and the vanilla tarballs on a branch (specifically the vendor branch). That's rather counterintuitive at first, but you quickly get used to it. (P.S. If this is generally unworkable to 'catch up' to Rev C, I'll just redo my changes on that version before Rev D comes out, and start from there) Shouldn't be a problem: - import A - check out a sandbox * copy your modified directory tree over top of it * commit - import B (if you're feeling in a rigorous mood) - import C - merge - commit - optionally: - more changes - commit + import D when it comes out + merge + commit That's assuming I read your post correctly, that your changes are still with respect to A, i.e. you're two releases behind. If that's wrong, move the *'ed steps to after the appropriate import. Once you've got it all CVSified, the +'ed steps are what you'll have to do every time you get a new release. In the recipe above, I left out all the tags. It's a good idea to tag the trunk both before and after every merge of a new vendor version. 90% of the time you won't need those tags, but when (not if) you do, you'll be *really* glad you made them. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [...] despite reports to the contrary, it is the rare programmer who permanently loses his sanity while coding (permanently being the operative word). - Eric E. Allen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [commit aborted] cannot rename file ,xxx, to file,v: file exists
McMurray, James writes: cvs.exe [commit aborted] cannot rename file ,filename, to filename,v: file exits. ,filename, is the new RCS file -- after it's been completely written successfully, CVS renames it to filename,v, atomically replacing the existing RCS file (if any). This ensures that you don't get a partial RCS file (or *no* RCS file!) if the system just happens to crash at an inopportune time. In your case, that rename is failing, which indicates some kind of a permission problem in the repository. The most common source of screwy permission problems is using a network file system (particularly Samba) to access the repository rather than using client/ server CVS like you should. -Larry Jones The real fun of living wisely is that you get to be smug about it. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: $CVS_USER won't expand in loginfo...
Rudman, Chris writes:
I'm using CVS v1.11 and i just can't seem to get the $CVS_USER environment
variable expanding in any of my *info files.
Environment variables aren't expanded in *info files (although they are
usually expanded in scripts called from *info file).
I can get $USER to expand, but this of course
expands into 'cvsowner' as the server user, and not the actual CVS user who
performed the commit. I've tried all sotrs of forms ($CVS_USER,
$CVS_USERNAME, %CVS_USER_NAME, ${CVS_USER}, etc etc), and i always get the
same error reported back:cvs server: loginfo:27: no such internal variable
$CVS_USER.
Perhaps you should try looking up internal variable in the fine
manual:
http://www.cvshome.org/docs/manual/cvs_18.html#SEC178
In my loginfo file i only have a single line:-
^cgr_test /export/cvs/CVSROOT/loginfo.ksh $CVS_USER %{sVv}
The internal variable you want is $USER (not to be confused with the
environment variable of the same name which, as you note, contains the
wrong user). That will set the first argument in your script ($1 for
ksh) to the CVS user name; it will not set any environment variables.
Newer versions of CVS set the $CVS_USER environment variable to the
value of the $USER internal variable, but I don't remember whether 1.11
is new enough to do that or not.
-Larry Jones
Is it too much to ask for an occasional token gesture of appreciation?!
-- Calvin
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Adding different files in same directory to differentrepositories...
Hi All, I have a project whereby i package different files into different components (but the files can work in conjunction) so are in the same directory. However, as many developers work on their own components i would really like to be able to have them in different CVS repositories. eg: Is there a way i can have: /home/simran/files/one.txt /home/simran/files/two.txt In a repository named files1 and the following: /home/simran/files/three.txt /home/simran/files/four.txt In a repository named files2 and check them out into the _same_ directory (files) and work on them. A way i can think this can happen is that i have a manifest file (kind of like he CVS/Entries file) of sorts for each repository which lists all the files in that reposity and cvs only looks at entries in that files to see which files i want to commit/updated/... simran. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS server process still running long after command is executed
Jeeva Sarma wrote: Hi all I have received no replys for this question whish I posted 2 days ago. The primary reason for that would be that you gave no information from which an answer could be derived. First, check if your server is set up so that it logs all its output - if not, reconfigure it to do so (on Unix systems, just use output redirection to file; if you are using a Windows server, check the manual for that system to see how, or if, this can be done). Once your server logs its output, just do your usual until the process hangs, then check the log. If you are on a Unix server, kill the CVS process (do NOT `kill -9` it!) to flush the file. Now read the end of the file - that should give you some idea of what the problem is. Have no one ever faced this problem?Can someone tell me atleast the reason for the cvs processes not dying?It only happens sometimes,not always.The server eventually freezes. Sounds like you've got a resource comsumption problem. Off the top of my head, I'd guess that the problem is not CVS, but a CVS script (commitinfo, taginfo, etc.) going infinitely recursive or somesuch. If you are using scripts, check your process list to see if any of them are running when CVS hangs. If so, there's your culprit. /|/|ike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
