CVS Login Eror
Title: CVS Login Eror OK, so i finally got my CVS server set up using pserver and i can import, and checkout using WinCVS and MacCVS clients. But when i make a mod and then try to do a commit on a file in either WinCVS or MacCVS, i get the following error: cvs commit -m Test xmain.cpp Milestones (in directory Macintosh HD:CVSROOT:Test1:) cvs commit: authorization failed: server 192.168.55.21 rejected access I can manually log in, i can execute import and checkout commands successfully - all with code 0 as the result, so i know i am connecting to the server ok, but it almost as if when i go to do a checkin that the server rejects my password or login info. Does anyone know what is going on? Thanks, -m -
Please remove me from this list
Please remove for this list because the traffic is too high for me. Crosby. [EMAIL PROTECTED]
Antwort: Question about files commit between two tags
Hi. 1) Does anyone know how to generate a report for all the files in CVS that were modified between two tags? I used "cvs log" command but i shows all the files not just the ones that were modified. Have a look at the command rdiff with the option -s. This should provide a summary as you requested. Ciao, Rene ... Rene Fertig TeleBeL GmbH Abt. Netzbetrieb Gesellschaft fuer Telekommunikation Bergisches Land Tel: +49 202 27167-223Johannisberg 7 Fax: +49 202 27167-283D-42103 Wuppertal Mobil: +49 172 2035310Germany eMail: [EMAIL PROTECTED]http://www.telebel.de ...
Serverlogging
Hi. Is there a way to do logging at the serverside? The $CVS_CLIENT_LOG only affects at the client-side, right? But I want to log at the sever-side who's connect to the server and who checkout/checkin which files. Bye, Rene ... Rene Fertig TeleBeL GmbH Abt. Netzbetrieb Gesellschaft fuer Telekommunikation Bergisches Land Tel: +49 202 27167-223Johannisberg 7 Fax: +49 202 27167-283D-42103 Wuppertal Mobil: +49 172 2035310Germany eMail: [EMAIL PROTECTED]http://www.telebel.de ...
Re: Serverlogging
I have no idea about this from the point of the CVS server, but you could always wrapper the server in, say, perl, start your program from inetd and capture the input and output of the process to some file someplace, while passing it to/from the cvs program. Cheers James Message History From: [EMAIL PROTECTED] on 02/06/2000 07:15 To: [EMAIL PROTECTED] cc: Subject: Serverlogging Hi. Is there a way to do logging at the serverside? The $CVS_CLIENT_LOG only affects at the client-side, right? But I want to log at the sever-side who's connect to the server and who checkout/checkin which files. Bye, Rene ... Rene Fertig TeleBeL GmbH Abt. Netzbetrieb Gesellschaft fuer Telekommunikation Bergisches Land Tel: +49 202 27167-223Johannisberg 7 Fax: +49 202 27167-283D-42103 Wuppertal Mobil: +49 172 2035310Germany eMail: [EMAIL PROTECTED]http://www.telebel.de ...
Re: Repository permission problem?
man chmod and pay close attention to "chmod g+s" (ie setgid for directories), then do: find $CVSROOT -type d | xargs chmod g+s Noel [EMAIL PROTECTED] on 06/01/2000 08:38:23 PM To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: Repository permission problem? Hello! I think I'm falling into the grey area between the FAQ and preexisting UNIX admin knowledge, was wondering if someone could tell me what I'm doing wrong, as I've tried the 7-8 conflicting answers I've found online. Problem: When user checks something in, they now own the file/dir, not cvs group! I am currently using: chmod -R 775 /home/cvs/cvsroot chown -R cvsowner:cvs /home/cvs/cvsroot All cvs users are members of group cvs. I'm running RedHat 6.2 w/ the env tweak in inetd.conf. Any help greatly appreciated. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: forced updates
"cvs edit" then "cvs unedit" will not necessarily retrieve a clean copy of the file. "cvs unedit" retrieves the copy of the file the way it was when "cvs edit" was done, modifications and all. Noel [EMAIL PROTECTED] on 06/01/2000 08:59:53 PM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Noel L Yap) Subject: Re: forced updates Just delete the file. CVS will notice that it is missing and fetch a fresh copy from the repository. The other option is to "cvs edit" the file, then "cvs unedit" when you are done with it. Both of these are available in the WinCVS interface. The "cvs edit" saves a copy of the file. The "cvs unedit" will prompt you to see if you want to overwrite the modified file. In the situation that you are asking about, you would just answer yes. Shane "Dimitrie O. Paun" wrote: Hi, Very often I run in this problem: I edit some files to add debugging stuff, and after a while I want to updated from CVS and to simply _overwrite_ the changes I made. I know, I can delete the files and then update. But, this is difficult 'cause sometimes I don't know what I've modified (and the files are scattered in hundreds of directories). Questions: 1) can I do this in one shot? 2) can I do it on the command line? 3) can I do it in WinCVS? TIA, Dimi. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
mistake in CVSROOT/commitinfo
I made a mistake in the commitinfo file, so now whenever I try to commit any file I get a "cvs server: Pre-commit check failed" error. Unfortunately, I'm unable to fix the mistake in commitinfo, since I can't commit the fixed commitinfo file. I've used "cvs admin -o" to remove the improper commitinfo version, but it is still using the bad commitinfo file. Is there a way to "Rebuild the database" for the CVSROOT directory? cvs 1.10 Thanks! Jeff
server file descriptors not being closed
I'm having problems adding functionality that uses the client/server protocol. After so many calls to send_file_names(), the server starts getting "Too many open files" errors on a call to pipe(protocol_pipe). I suspect that somewhere on the server, file descriptors aren't being closed. The problem is that it's extremely difficult to hunt down. Larry, IIRC, at one point you said you run CVS through Purify. Does it say what file descriptors are still open on the server side? Thanks, Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: mistake in CVSROOT/commitinfo
Cumming, Jeff writes: I made a mistake in the commitinfo file, so now whenever I try to commit any file I get a "cvs server: Pre-commit check failed" error. Unfortunately, I'm unable to fix the mistake in commitinfo, since I can't commit the fixed commitinfo file. I've used "cvs admin -o" to remove the improper commitinfo version, but it is still using the bad commitinfo file. Is there a way to "Rebuild the database" for the CVSROOT directory? I think ``cvs init'' will do that. If not, you can put the fixed commitinfo file into $CVSROOT/CVSROOT manually -- then you'll be able to commit it properly. -Larry Jones They can make me do it, but they can't make me do it with dignity. -- Calvin
Re: mistake in CVSROOT/commitinfo
You'll have to directly go into the repository and remove it manually. Noel [EMAIL PROTECTED] on 06/02/2000 11:58:33 AM To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: mistake in CVSROOT/commitinfo I made a mistake in the commitinfo file, so now whenever I try to commit any file I get a "cvs server: Pre-commit check failed" error. Unfortunately, I'm unable to fix the mistake in commitinfo, since I can't commit the fixed commitinfo file. I've used "cvs admin -o" to remove the improper commitinfo version, but it is still using the bad commitinfo file. Is there a way to "Rebuild the database" for the CVSROOT directory? cvs 1.10 Thanks! Jeff This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
end of file from server message
Can someone tell me why I would get this message from an NT machine when trying to checkout a tree (the message isn't particularly helpful)? I have had good success when checking out files from Linux clients and a Windows 98 client, but for some reason, I get this message when attempting a check out from an NT client. I'm thinking that I must have done something to the 98 machine to get it to work correctly, but I can't, for the life of me, remember what it was. I have set the CVSROOT environment variable and the remote machine's IP address is in the .rhosts file as it should be. What am I forgetting? The server is a Linux box running cvs 1.10.6, and the client is NT 4.0 running cvs 1.10 (and I am using the internal rsh protocol method of connecting to the server). Thanks, - Dennis winmail.dat
Editing the $CVSROOT/CVSROOT/passwd file.
Hi. I'm having some problems with our CVS here. When we add a new user to the CVS we checkout/update our CVSROOT directory copy and add the new user and then commit the changed files (usually passwd and writers). Unfortunately, the passwd file isn't correctly updated and this makes necessary to keep someone with shell access to that machine. Is this a problem or a common behaviour of the system? All administrative files are correctly updated with the only exception of passwd. It's ",v" file is updated correctly, thought. Any hints? Thanks, -- Godoy. [EMAIL PROTECTED] Departamento de Publicações Publishing Department Conectiva S.A.
Logging changes w/ CVS
Hi, I think I subscribed at egroups to get this list, if that's not right please let me know ... Sorry for the length, but I need to describe where I'm coming from. I've been using a DOS port of RCS for a many years and have developed some Korn Shell scripts to automate my check in of projects. (using MKS's ksh for dos). The main problem I had with RCS besides automating the checkin to process the whole project, was incorporating change log messages. I could type them in after the fact if I could remember all the changes I had made. I might normally work on changes for several weeks before checking in a new project version, making many changes in dozens of files, so remembering changes after the fact is impossible. I finally developed a system where I opened a log file for each source file I was editing in a subdirectory named log with the same name as the source file. I use a shell script to check in each source file which has an existing log file, and the log file is redirected to the RCS ci command for use as the log message. I use "$Log:$" comments in the source so RCS adds the log to the source file. All the individual log files are also added to a main project log file. This lets me make notes in the log files as I make the changes in the source files. However it is a PITA because I must manually maintain lists that tells my scripts which files to check in etc. CVS uses RCS, so the RCS variables I am used to including in my source will still work right? What about automatically including log files for the log messages. Since the commit process automatically checks in all the changed files, is there anyway to make it use individual log files for each source file? From my reading so far, it looks like CVS provides fewer logging options than plain RCS. Only a -F and -m which puts the same log message in each source file. I need an option like -F which puts a different log file message with each source file. The other option, entering log messages after the fact with an editor has the problems of remembering the changes after the fact. Since CVS is supposed to be for concurrent development among many developers, I'm surprised that the change logging features are no more advanced than plain RCS, or have I missed something? Thanks, Cla.
Re: Repository permission problem?
On Thu, Jun 01, 2000 at 17:38 -0700, Kerry L. Bonin wrote: Problem: When user checks something in, they now own the file/dir, not cvs group! I am currently using: chmod -R 775 /home/cvs/cvsroot chown -R cvsowner:cvs /home/cvs/cvsroot Use setgid on the *directories*, and yes it gets asked quite often. :) I'm running RedHat 6.2 w/ the env tweak in inetd.conf. There's a doc directory on the first of the CDs (at least it was in RH6.0 and RH5.2). There you will find a discussion on user and group ownerships and the method RedHat uses (USG(sp?)). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Re: end of file from server message (add'l info)
Dennis Jones writes: The server is a Linux box running cvs 1.10.6, and the client is NT 4.0 running cvs 1.10 (and I am using the internal rsh protocol method of connecting to the server). Are you sure you're using the internal rsh method on NT? CVS 1.10.6 has a bug in pserver mode that causes exactly this problem. -Larry Jones My "C-" firmly establishes me on the cutting edge of the avant-garde. -- Calvin
Re: Editing the $CVSROOT/CVSROOT/passwd file.
Be sure you added 'passwd' to $CVSROOT/CVSROOT/checkoutlist To: [EMAIL PROTECTED] cc: (bcc: Hal Wine/HMG/Wilson Learning/US) Subject: Editing the $CVSROOT/CVSROOT/passwd file. Hi. I'm having some problems with our CVS here. When we add a new user to the CVS we checkout/update our CVSROOT directory copy and add the new user and then commit the changed files (usually passwd and writers). Unfortunately, the passwd file isn't correctly updated and this makes necessary to keep someone with shell access to that machine. Is this a problem or a common behaviour of the system? All administrative files are correctly updated with the only exception of passwd. It's ",v" file is updated correctly, thought. Any hints? Thanks, -- Godoy.[EMAIL PROTECTED] Departamento de Publica ções Publishing Department Conectiva S.A.
Re: Editing the $CVSROOT/CVSROOT/passwd file.
Create a file in CVSROOT called checkoutlist. Add each file you want automatically checked out into this file. Noel [EMAIL PROTECTED] on 06/02/2000 02:43:59 PM To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: Editing the $CVSROOT/CVSROOT/passwd file. Hi. I'm having some problems with our CVS here. When we add a new user to the CVS we checkout/update our CVSROOT directory copy and add the new user and then commit the changed files (usually passwd and writers). Unfortunately, the passwd file isn't correctly updated and this makes necessary to keep someone with shell access to that machine. Is this a problem or a common behaviour of the system? All administrative files are correctly updated with the only exception of passwd. It's ",v" file is updated correctly, thought. Any hints? Thanks, -- Godoy.[EMAIL PROTECTED] Departamento de Publicações Publishing Department Conectiva S.A.
RE: end of file from server message (add'l info)
Yes I'm sure -- and I think I just found the problem. The user names in the NT domain were entered with mixed case (don't ask me why), but users don't know this since NT doesn't enforce case sensitivity when you log in. The user accounts I created on the Linux server machine (the one with CVS on it) were all in lower case. I don't know what made me think of it, but I tried creating an additional username with mixed case that matched the case of the username in the NT domain, did a checkout, and it worked. Now, the next question is, can I get it to work without having to re-enter all the usernames on the Linux server? You cannot simply add the username to the CVSROOT variable like this: set CVSROOT=myname@CVSSERVER:/path to repository because CVS complains about the mixed case name (as logged in) not matching the one that's all lower case (specified in the CVSROOT variable). It says something like, "cannot log in as local user 'MyName', remote user 'myname' I guess I have no choice but to re-enter all the usernames on the Linux server. - Dennis -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, June 02, 2000 12:33 PM To: Dennis Jones Cc: [EMAIL PROTECTED] Subject: Re: "end of file from server" message (add'l info) Dennis Jones writes: The server is a Linux box running cvs 1.10.6, and the client is NT 4.0 running cvs 1.10 (and I am using the internal rsh protocol method of connecting to the server). Are you sure you're using the internal rsh method on NT? CVS 1.10.6 has a bug in pserver mode that causes exactly this problem. -Larry Jones My "C-" firmly establishes me on the cutting edge of the avant-garde. -- Calvin
RE: end of file from server message (add'l info)
Are you sure the .rhosts files are correct (ie with the mixed case names)? Noel [EMAIL PROTECTED] on 06/02/2000 03:55:11 PM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Noel L Yap) Subject: RE: "end of file from server" message (add'l info) Yes I'm sure -- and I think I just found the problem. The user names in the NT domain were entered with mixed case (don't ask me why), but users don't know this since NT doesn't enforce case sensitivity when you log in. The user accounts I created on the Linux server machine (the one with CVS on it) were all in lower case. I don't know what made me think of it, but I tried creating an additional username with mixed case that matched the case of the username in the NT domain, did a checkout, and it worked. Now, the next question is, can I get it to work without having to re-enter all the usernames on the Linux server? You cannot simply add the username to the CVSROOT variable like this: set CVSROOT=myname@CVSSERVER:/path to repository because CVS complains about the mixed case name (as logged in) not matching the one that's all lower case (specified in the CVSROOT variable). It says something like, "cannot log in as local user 'MyName', remote user 'myname' I guess I have no choice but to re-enter all the usernames on the Linux server. - Dennis -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, June 02, 2000 12:33 PM To: Dennis Jones Cc: [EMAIL PROTECTED] Subject: Re: "end of file from server" message (add'l info) Dennis Jones writes: The server is a Linux box running cvs 1.10.6, and the client is NT 4.0 running cvs 1.10 (and I am using the internal rsh protocol method of connecting to the server). Are you sure you're using the internal rsh method on NT? CVS 1.10.6 has a bug in pserver mode that causes exactly this problem. -Larry Jones My "C-" firmly establishes me on the cutting edge of the avant-garde. -- Calvin This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
cvs add
I have a question regarding the 'add' command in cvs. The repository in our group is somehow exhibiting the following behavior: when someone creates a new directory in his local version, then does a 'cvs add', it appears that no one else in the group gets the new directory when doing an 'update' subsequent to this action. The file permissions in the repository appear fine and the cvs directory and log files appear fine in the new, local directory of the person who created it. Any ideas why this is happening? We seem to be unable to create a directory, add it to the repository, and have everyone update this new directory. Thanks, Ken
