RE: cvs [commit aborted]: Invalid Lockserver version - got 1.2, w anted 2.1
Robert Lewis wrote: I have searched thru the mail lists but can not find a solution to the problem. This error occurs for any operation I try to due. Mostly I was just trying to do a commit as a test. cvs [commit aborted]: Invalid Lockserver version - got 1.2, wanted 2.1 I am using Windows XP home edition sp2, CVSNT2.0.21, While CVSNT and the standard GNU CVS are similar, there are differences, and the lock server is one of them. You'll get more knowledgeable assistance on a mail list that focuses on CVSNT. Unfortunately, I don't have any links I can provide you. A quick search through the archives for this list might turn up something. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: Invalid Lockserver version - got 1.2, wanted 2.1
I have searched thru the mail lists but can not find a solution to the problem. This error occurs for any operation I try to due. Mostly I was just trying to do a commit as a test. cvs [commit aborted]: Invalid Lockserver version - got 1.2, wanted 2.1 I am using Windows XP home edition sp2, CVSNT2.0.21, and tortoise-cvs 1.8.10, as a local system. There are no network database connections, or other networks for that matter apart from the Internet connection. The system has worked fine for about a year. Today I had the misfortune to install 1.8.11 of Tortoise-cvs and now I get the above error. Un-installing Tortoise and going back to 1.8.10 did not help. The error persists. I can find no information on the Tortoise-cvs site on the error. I also renamed the directory I work under and copied down an archive of the client directory (mine), but I still get the error Should I remove and re-install CVS or is there a newer CVS I should be using? It seems to me that it is mixing up the order of its bytes somewhere. Any advice would be appreciated, this has brought all my work to a halt. Thank you. Robert Lewis ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: invalid change text
I am getting an error trying to update a unicode file. Here is what I am seeing: cvs commit -m no message dbo.CitNewsSelect.PRC (in directory S:\CityOfSammamish\bin\sql\) Removing dbo.CitNewsSelect.PRC; cvs commit: Dropping data: posvec-nlines cvs [commit aborted]: invalid change text in c:/cvsroot/CityOfSammamish/bin/sql/dbo.CitNewsSelect.PRC,v * CVS exited normally with code 1 * I would like to remove this file and start from scratch, which I tried to do. I was able to mark it deleted, but now am unable to commit it to actually remove it from the repository. Help! Andy ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: invalid change text
When I came in this morning things seemed clearer. I just deleted the file dbo.CitNewsSelect.PRC,v from cvsroot, updated the directory, and re-added. Works like a charm. Only problem is I lost all previous history on the file... might be nice to avoid that if possible. If anyone knows how to do this in a less drastic way, let me know. Andy Andy Stringer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I am getting an error trying to update a unicode file. Here is what I am seeing: cvs commit -m no message dbo.CitNewsSelect.PRC (in directory S:\CityOfSammamish\bin\sql\) Removing dbo.CitNewsSelect.PRC; cvs commit: Dropping data: posvec-nlines cvs [commit aborted]: invalid change text in c:/cvsroot/CityOfSammamish/bin/sql/dbo.CitNewsSelect.PRC,v * CVS exited normally with code 1 * I would like to remove this file and start from scratch, which I tried to do. I was able to mark it deleted, but now am unable to commit it to actually remove it from the repository. Help! Andy ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
commit aborted
When I try to commit some files on cvs server, I take the following error: cvs commit -m no message ContainerPUC.cs (in directory C:\Local-GrASP-CVS\instantiation_location\EU-GrASP\src\GrASP\Container\Conta inerPUC\) cvs commit: Empty password used - try 'cvs login' with a real password cvs [commit aborted]: authorization failed: server cvs.rus.uni-stuttgart.de rejected access to /usr/cvsroot/Grasp for user crmpa_rovezzi But, I am not the user crmpa_rovezzi. How I can resolve this problem? thanks in advance Nadia ___ 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
[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: [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 [commit aborted]: reading 'myfile': File too large
On 4/23/02 at 7:27 PM, [EMAIL PROTECTED] (Robert J. Clark) wrote: That error message is generated by the client with it tries to examine or open the file to be sent to the server. Try doing a stat filename on the file that is failing and see if that provides any useful information about the file. Looks like the stat command is not included in Mac OS X. I copied the trouble file to my linux server (yellow dog linux) and ran the stat command with the following results: File: CBN3106_06.deb Size: 234558 Blocks: 472 Regular File Access: (0666/-rw-rw-rw-) Uid: ( 501/gdelfino) Gid: ( 503/gdsolutions) Device: 819Inode: 343048 Links: 1 Access: Tue Apr 23 20:16:18 2002 Modify: Tue Apr 23 20:16:18 2002 Change: Tue Apr 23 20:16:18 2002 I think the error is generated when trying to access a file that is larger than a 32-bit file offset can handle. In this case the file should be opened with O_LARGEFILE set. However, based on your previous messages, I don't believe this is the case. Is a copy of the file already checked in? If so, what is it's size on the server? Pardon my ignorance, but can how can I tell cvs to open the file using the O_LARGEFILE option? The problem happens when trying to check in the file for the first time. Right now I would be inclined to think that there is something corrupted in the filesystem for the file you are trying to check in. - Rob I would like to report that I have finally been able to upload my file. I used the windows version of cvs (1.10) instead of the unix version. Not exactly a solution, but I solved my problem. My working directory is on a Windows 2000 machine wich I access via SMB from my Mac OS X machine. Instead of running cvs from my Mac, I did it directly from the PC. By the way, I have been unable to access cvshome.org for the last 2 or 3 days. Regards, Gustavo Delfino ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: reading 'myfile': File too large
Gustavo Delfino writes: My working directory is on a Windows 2000 machine wich I access via SMB from my Mac OS X machine. That's undoubtedly the problem. Windows is screwy, SMB is doubly screwy, and SMB on Mac is likely screwy squared. -Larry Jones What's the matter? Don't you trust your own kid?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: reading 'myfile': File too large
My text file has 605 lines and 396 columns of text, the size is 232k. The file has DOS line endings, and I' using cvs 1.10 on the client Mac OS X 10.1.4 machine, and the server is cvs 1.11 running on FreeBSD 4.4-RELEASE I have looked on the cederqvist manual, and mailing lists, FAQs and google without any luck. Any idea of what is going on? Thanks in advance Gustavo Caracas, Venezuela ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: reading 'myfile': File too large
On Tue, Apr 23, 2002 at 09:07:34AM -0400, Gustavo Delfino wrote: My text file has 605 lines and 396 columns of text, the size is 232k. Where is the file 605 lines, and where is it 232 K? If you mean that the checked-out copy is 605 lines and that the copy in the repository is 232 K, that seems totally reasonable, provided you've made a lot of revisions. The whole point of a versioning system is that it retains information about your previous versions. (Go look at the file within the repository. Don't worry, you won't break anything as long as you only read() it.) -- gabriel rosenkoetter [EMAIL PROTECTED] msg20160/pgp0.pgp Description: PGP signature
Re: cvs [commit aborted]: reading 'myfile': File too large
On Tue, Apr 23, 2002 at 09:46:03AM -0400, gabriel rosenkoetter wrote: On Tue, Apr 23, 2002 at 09:07:34AM -0400, Gustavo Delfino wrote: My text file has 605 lines and 396 columns of text, the size is 232k. Where is the file 605 lines, and where is it 232 K? Ahem. I read your message but not your subject, so I completely misunderstood your problem. My apologies. Try doing a cvs -t commit and see if the trace messages help any. -- gabriel rosenkoetter [EMAIL PROTECTED] msg20161/pgp0.pgp Description: PGP signature
Re: cvs [commit aborted]: reading 'myfile': File too large
On 4/23/02 at 9:46 AM, [EMAIL PROTECTED] (gabriel rosenkoetter) wrote: On Tue, Apr 23, 2002 at 09:07:34AM -0400, Gustavo Delfino wrote: My text file has 605 lines and 396 columns of text, the size is 232k. Where is the file 605 lines, and where is it 232 K? If you mean that the checked-out copy is 605 lines and that the copy in the repository is 232 K, that seems totally reasonable, provided you've made a lot of revisions. The whole point of a versioning system is that it retains information about your previous versions. (Go look at the file within the repository. Don't worry, you won't break anything as long as you only read() it.) -- gabriel rosenkoetter [EMAIL PROTECTED] Thank you Gabriel for your answer. The file is not yet on the repository. I did a 'cvs add myfile' without problems. The problem is that I get that error (see subject) when I do a 'cvs ci -m message myfile'. I opened my file in xemacs and realized that it has 605 lines and 396 columns. Yes, it is a *very* wide file, but I can not modify this file. In fact, once I commit this file I will not modify it, as this is a test file. The 232k is just an estimate of the file size, which in my opinion is not too large. An 'ls -lh' command returns the following: -rwxr-xr-x1 gdelfino wheel232k Apr 19 10:29 CBN3106_06.deb Regards, Gustavo Delfino Caracas, Venezuela ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: reading 'myfile': File too large
On 4/23/02 at 10:25 AM, [EMAIL PROTECTED] (gabriel rosenkoetter) wrote: Ahem. I read your message but not your subject, so I completely misunderstood your problem. My apologies. Try doing a cvs -t commit and see if the trace messages help any. That didn't help. The only additional message was Sending file `CBN3106_06.deb' to server. Any other ideas? I suspect that the keyword substitution algorithm may be failing for such a wide file. Is there a way to turn off keyword substitution? Regards, Gustavo Delfino ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: reading 'myfile': File too large
On Tue, Apr 23, 2002 at 09:07:34AM -0400, Gustavo Delfino wrote: I' using cvs 1.10 on the client Mac OS X 10.1.4 machine, and the server is cvs 1.11 running on FreeBSD 4.4-RELEASE Those are both *ancient* CVS releases. Try upgrading them. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Outlook not so good. That magic 8-ball knows everything! I'll ask about Exchange Server next. - Anonymous ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: reading 'myfile': File too large
Gustavo Delfino writes: I suspect that the keyword substitution algorithm may be failing for such a wide file. Is there a way to turn off keyword substitution? There is, but that's not the problem. Keyword substitution doesn't happen until checkout/update (which happens automatically *after* a commit if keywords are detected in the file) and you're not getting that far. Based on the error message, it would appear to be a client-side problem -- I suggest upgrading the client to the most recent release of CVS (1.11.2) and see if that doesn't fix the problem. -Larry Jones Rats. I can't tell my gum from my Silly Putty. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: reading 'myfile': File too large
On 4/23/02 at 12:43 PM, [EMAIL PROTECTED] (Eric Siegerman) wrote: Those are both *ancient* CVS releases. Try upgrading them. On 4/23/02 at 1:29 PM, [EMAIL PROTECTED] (Larry Jones) wrote: There is, but that's not the problem. Keyword substitution doesn't happen until checkout/update (which happens automatically *after* a commit if keywords are detected in the file) and you're not getting that far. Based on the error message, it would appear to be a client-side problem -- I suggest upgrading the client to the most recent release of CVS (1.11.2) and see if that doesn't fix the problem. -Larry Jones I have upgraded cvs on my Mac OS X machine from 1.10 to 1.11 using fink (a Mac OS X package manager). The problem is still there, but now the trace option give a little more information: cvs -t ci -m message filename cvs commit: notice: main loop with CVSROOT=:pserver:mylogin@servername:/usr/local/cvs/abc - Sending file `filename' to server cvs [commit aborted]: reading filename: File too large I'll try to upgrade from 1.11 to 1.11.2, but this is not going to be easy for me as that version is not in fink yet, and Mac OS X/Darwin is not on the list of tested platforms for 1.11.2 and I'm not an expert compiling code. Regards, Gustavo Delfino ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: reading 'myfile': File too large
On Tue, 23 Apr 2002 19:00:15 -0400 Gustavo Delfino [EMAIL PROTECTED] wrote: On 4/23/02 at 12:43 PM, [EMAIL PROTECTED] (Eric Siegerman) wrote: Those are both *ancient* CVS releases. Try upgrading them. On 4/23/02 at 1:29 PM, [EMAIL PROTECTED] (Larry Jones) wrote: There is, but that's not the problem. Keyword substitution doesn't happen until checkout/update (which happens automatically *after* a commit if keywords are detected in the file) and you're not getting that far. Based on the error message, it would appear to be a client-side problem -- I suggest upgrading the client to the most recent release of CVS (1.11.2) and see if that doesn't fix the problem. -Larry Jones I have upgraded cvs on my Mac OS X machine from 1.10 to 1.11 using fink (a Mac OS X package manager). The problem is still there, but now the trace option give a little more information: cvs -t ci -m message filename cvs commit: notice: main loop with CVSROOT=:pserver:mylogin@servername:/usr/local/cvs/abc - Sending file `filename' to server cvs [commit aborted]: reading filename: File too large That error message is generated by the client with it tries to examine or open the file to be sent to the server. Try doing a stat filename on the file that is failing and see if that provides any useful information about the file. I think the error is generated when trying to access a file that is larger than a 32-bit file offset can handle. In this case the file should be opened with O_LARGEFILE set. However, based on your previous messages, I don't believe this is the case. Is a copy of the file already checked in? If so, what is it's size on the server? Right now I would be inclined to think that there is something corrupted in the filesystem for the file you are trying to check in. - Rob ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
Since switching to the latest CVS development code base, I now get different results: $ cvs -t update build.xml cvs update: notice: main loop with [EMAIL PROTECTED]:/space/cvsroot - Starting server: ssh xx.xx.xx.xx -l dhoag cvs server S- Reader_Lock(/space/cvsroot/build) S- Lock_Cleanup() I've let it sit like this for over 30 minutes. Meanwhile another a different machine and network: $ cvs -t update build.xml - main loop with [EMAIL PROTECTED]:/space/cvsroot - Starting server: ssh xx.xx.xx.xx -l dhoag cvs server S- Reader_Lock(/space/cvsroot/build) S- Lock_Cleanup() S- Lock_Cleanup() On the CVS server $ ps -ef | grep cvs dhoag 22624 22623 0 16:36:25 ?0:00 cvs server $ ls -l /tmp/cvs-serv22624/CVS/Entries -rw-r--r-- 1 dhoagstaff 19 Feb 16 16:36 /tmp/cvs-serv22624/CVS/Entries $ ls -l /tmp/cvs-serv22624/CVS/Repository -rw-r--r-- 1 dhoagstaff 21 Feb 16 16:36 /tmp/cvs-serv22624/CVS/Repository Any ideas why it hangs? - Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
[EMAIL PROTECTED] (Larry Jones) wrote in message news:[EMAIL PROTECTED]... Manually killing a server process will cause a connection reset error at the client. If you don't kill the server process, do you still get the client error and, if so, is the server process still running afterwards or has it died? Give me a little credit here. I don't kill the process until long after the client has died. I realize that if I had killed the process prior to the client dieing I would get the connection reset error. The server process is simply lingering (probably waiting for the below mentioned timeout) after my client dies. The only timeout in CVS is that the server uses TCP/IP Keep-Alive to detect clients that disappear without properly closing their connections, but that usually takes hours to kick in. I didn't get a chance to try it out last night, perhaps sometime this weekend. I'll keep you posted. Thanks again, - Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
David Hoag writes: Give me a little credit here. I don't kill the process until long after the client has died. I realize that if I had killed the process prior to the client dieing I would get the connection reset error. The server process is simply lingering (probably waiting for the below mentioned timeout) after my client dies. In that case, you've almost certainly got some kind of a network problem. You need to run netstat on the server to find out for sure what state the connections are in. The client died because the connection was forcibly closed -- under normal circumstances, that would cause the server to die, too. -Larry Jones Well, it's all a question of perspective. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
Larry, thanks for your patience. Like I said: When I SSH to the CVS server I see many CVS SERVER processes on the box (via ps -ef ). So, clearly my server processes are not leaving core files (since they are not dieing). The /tmp/cvs-serv* directories do exist, and they're empty. It appears as if the both the server and client process is just sitting there. When I run the client I can use the -t option to show a client side trace. I was wondering if there was someway to turn on some server side verbose logging to help resolve my problems. From your previous reply it sounds as if my only choice at this time is run the developement version of the server. Is there anything I need to do to see the recently added log messages? Where do the messages go? Standard out? - Dave [EMAIL PROTECTED] (Larry Jones) wrote in message news:[EMAIL PROTECTED]... David Hoag writes: Im guessing its related to a slow internet connection (110kb - faster than dialup) or something about my provider. Any ideas where to look? Like I said: Look in the server's TempDir (usually /tmp) for leftover cvs-serv* directories and core files -- if there aren't any, the server isn't crashing. That will at least let us know whether the server is crashing or simply ending without sending any error message. If the server isn't crashing, you might want to try running the current development version of CVS on the server -- I recently made a change to send any pending output to the client before shutting down the server. -Larry Jones It's not denial. I'm just very selective about the reality I accept. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
David Hoag writes: Like I said: When I SSH to the CVS server I see many CVS SERVER processes on the box (via ps -ef ). But you also said, many people use this CVS server. Do the server processes you see come and go (which implies that they belong to other users) or do some of them stay around forever? So, clearly my server processes are not leaving core files (since they are not dieing). The /tmp/cvs-serv* directories do exist, and they're empty. If you're sure those are your server processes, it might be useful to run netstat to find out what state the connections are in. It appears as if the both the server and client process is just sitting there. I'm confused -- originally you said the client was ending with connection reset by peer and end of file from server error messages, now it appears that you're saying the client is hanging. Is this the same problem or a different one? Broken connections and hung connections are usually not caused by the same things. When I run the client I can use the -t option to show a client side trace. I was wondering if there was someway to turn on some server side verbose logging to help resolve my problems. The trace is unified -- some messages come from the client, others come from the server. From your previous reply it sounds as if my only choice at this time is run the developement version of the server. Is there anything I need to do to see the recently added log messages? Where do the messages go? Standard out? The messages get sent to the client, which should display them as error messages. -Larry Jones If I was being raised in a better environment, I wouldn't do things like that. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
But you also said, many people use this CVS server. Do the server processes you see come and go (which implies that they belong to other users) or do some of them stay around forever? The processes are owned by my user id. Started when I initiate a cvs update(or commit). They linger until I manually 'kill' them. The traffic on the CVS server is not 'a lot' by most standards. About 5 people using it daily from various locations. Sorry for the confusion. I'm confused -- originally you said the client was ending with connection reset by peer and end of file from server error messages, now it appears that you're saying the client is hanging. Is this the same problem or a different one? Broken connections and hung connections are usually not caused by the same things. The original error is the only error I've received. But what is not visible by the original post is the fact that the client doesn't die immediately ( I would guess there's a timeout value triggering the broken pipe). Again, I apologize if I confused the issue. The trace is unified -- some messages come from the client, others come from the server. I've built the latest cvs from a ccvs checkout. I'll try again tonight and report if I have any additional information. Thanks again, - Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
David Hoag writes: The processes are owned by my user id. Started when I initiate a cvs update(or commit). They linger until I manually 'kill' them. Manually killing a server process will cause a connection reset error at the client. If you don't kill the server process, do you still get the client error and, if so, is the server process still running afterwards or has it died? The original error is the only error I've received. But what is not visible by the original post is the fact that the client doesn't die immediately ( I would guess there's a timeout value triggering the broken pipe). Again, I apologize if I confused the issue. The only timeout in CVS is that the server uses TCP/IP Keep-Alive to detect clients that disappear without properly closing their connections, but that usually takes hours to kick in. -Larry Jones All girls should be shipped to Pluto--that's what I say. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
[EMAIL PROTECTED] (Larry Jones) wrote in message news:[EMAIL PROTECTED]... David Hoag writes: $ cvs -version Concurrent Versions System (CVS) 1.11 (client/server) ... more version info $ ssh -l dhoag 192.168.0.1 cvs -version Concurrent Versions System (CVS) 1.11 (client/server) ... more version info With CVS 1.11, you can just do cvs version (that's a command, not an option, so no -) to get both the client and server version information in one shot. Read from remote host 192.168.0.1: Connection reset by peer cvs [commit aborted]: end of file from server (consult above messages if any) That indicates that the server is closing the connection. That could be because it is crashing, or it could be because you've got some kind of access control software (e.g., tcpd) that's denying access to the server. Look in the server's TempDir (usually /tmp) for leftover cvs-serv* directories and core files -- if there aren't any, the server isn't crashing. -Larry Jones Philistines. -- Calvin Im guessing its related to a slow internet connection (110kb - faster than dialup) or something about my provider. Any ideas where to look? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
David Hoag writes: Im guessing its related to a slow internet connection (110kb - faster than dialup) or something about my provider. Any ideas where to look? Like I said: Look in the server's TempDir (usually /tmp) for leftover cvs-serv* directories and core files -- if there aren't any, the server isn't crashing. That will at least let us know whether the server is crashing or simply ending without sending any error message. If the server isn't crashing, you might want to try running the current development version of CVS on the server -- I recently made a change to send any pending output to the client before shutting down the server. -Larry Jones It's not denial. I'm just very selective about the reality I accept. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]:
I can not commit - Here's an example session: CVS server is on solaris, CVS client is on RedHat, Win98, or Win2k. I am behind a Nat router when accessing the cvs server (I've change the IP of the CVS server to protect the innocent). $ cvs -version Concurrent Versions System (CVS) 1.11 (client/server) ... more version info $ ssh -l dhoag 192.168.0.1 cvs -version Concurrent Versions System (CVS) 1.11 (client/server) ... more version info $ cvs -t -z 9 commit -m Updates to property holders BrokerProperty*.java cvs commit: notice: main loop with [EMAIL PROTECTED]:/space/cvsroot - Starting server: ssh 192.168.0.1 -l dhoag cvs server - Sending file `BrokerPropertyDetail.java' to server - Sending file `BrokerPropertySource.java' to server Read from remote host 192.168.0.1: Connection reset by peer cvs [commit aborted]: end of file from server (consult above messages if any) $ cvs -z 9 status BrokerPropertySource.java Read from remote host 192.168.0.1: Connection reset by peer cvs [status aborted]: end of file from server (consult above messages if any) Sometimes CVS update/status works. Cvs checkout always works. Any suggestions? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
David Hoag writes: $ cvs -version Concurrent Versions System (CVS) 1.11 (client/server) ... more version info $ ssh -l dhoag 192.168.0.1 cvs -version Concurrent Versions System (CVS) 1.11 (client/server) ... more version info With CVS 1.11, you can just do cvs version (that's a command, not an option, so no -) to get both the client and server version information in one shot. Read from remote host 192.168.0.1: Connection reset by peer cvs [commit aborted]: end of file from server (consult above messages if any) That indicates that the server is closing the connection. That could be because it is crashing, or it could be because you've got some kind of access control software (e.g., tcpd) that's denying access to the server. Look in the server's TempDir (usually /tmp) for leftover cvs-serv* directories and core files -- if there aren't any, the server isn't crashing. -Larry Jones Philistines. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]:
More information: When I SSH to the CVS server I see many CVS SERVER processes on the box (via ps -ef ). This problem appears to happen only from one set of IPs. While many people use this CVS server, I'm the only one experiencing problems ( and from only 1 location ). I have no problems with different machines on a couple of different networks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
commit aborted
Using WinCVS 1.2, everytime I try to commit a particular file i get the following message: cvs [commit aborted]: end of file from server What does this message mean, and how can I fix it so I can commit my file? = Robin Lunceford __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: commit aborted
Robin Lunceford writes: cvs [commit aborted]: end of file from server What does this message mean, and how can I fix it so I can commit my file? It means that the server has unexpectedly closed the connection to the client. In most cases, that means the server has encountered a serious error that it was unable to communicate to the client, it may even have crashed. If your server isn't running the latest release of CVS (1.11.1p1), you should upgrade it and see if it fixes the problem or at least gives you a better error message. Otherwise, I'm afraid you'll have to become familiar with a debugger (or find someone who is) and track the problem down yourself -- these kinds of problems really can't be diagnosed remotely. -Larry Jones TIME?! I just finished the first problem! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: out of memory; can not reallocate 95683558 bytes
Sachin wrote: Hi, I am trying bytes to checkin a big file of 95MB into a repository. I am woking on a HP-UX 10.20 system and CVS version is 1.11.1p. I am getting the following error messages, cvs [commit aborted]: out of memory; can not reallocate 95683558 TIA. First: Are you really sure you need to put that file under revision control? What is it? Second: The error message tells it all: cvs runs out of memory when it tries to swallow such a huge file. I don't know exactly where you've to add memory (are you working client/server or local?), but I guess at least you've to increase your swapspace. You may also run into trouble with insufficient temporary disk space. Have a look at http://www.cvshome.org/docs/manual/cvs_2.html#SEC37 Harald -- iXpoint Informationssysteme GmbH # Rheinstraße 79a # Harald Kucharek 76275 Ettlingen # [EMAIL PROTECTED] Tel/Fax +49 7243 3775-0/77# www.ixpoint.de ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: out of memory; can not reallocate 95683558 bytes
hi, Thanks for the info. I have checked that I have enough of swap and tmp space free. Inspite of that it gives me an error. I have tried checking in a file size of max 60 MB. After that it cribs and starts giving the memory error. there is some limitation from cvs side itself. any more help would b appreciated. thanks sachin Harald Kucharek [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Sachin wrote: Hi, I am trying bytes to checkin a big file of 95MB into a repository. I am woking on a HP-UX 10.20 system and CVS version is 1.11.1p. I am getting the following error messages, cvs [commit aborted]: out of memory; can not reallocate 95683558 TIA. First: Are you really sure you need to put that file under revision contr ol? What is it? Second: The error message tells it all: cvs runs out of memory when it tr ies to swallow such a huge file. I don't know exactly where you've to add memory (are you working client/server or local?), but I guess at least you've to increase your swapspace. You may also run into trouble with insufficient temporary disk space. Have a look at http://www.cvshome.org/docs/manual/cvs 2.html#SEC37 Harald ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: out of memory; can not reallocate 95683558 bytes
Sachin writes: Thanks for the info. I have checked that I have enough of swap and tmp space free. Inspite of that it gives me an error. I have tried checking in a file size of max 60 MB. After that it cribs and starts giving the memory error. there is some limitation from cvs side itself. any more help would b appreciated. There's no particular limit in CVS -- most likely you're running into some per-process limit. Most shells have a limit or ulimit command to display and modify the limits, but you usually have to be root to increase them. You'll have to consult your system documentation to find out how to increase the default values. -Larry Jones I'm writing you a message in code. How do you spell nincompoop? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: out of memory; can not reallocate 95683558 bytes
Hi, I am trying bytes to checkin a big file of 95MB into a repository. I am woking on a HP-UX 10.20 system and CVS version is 1.11.1p. I am getting the following error messages, cvs [commit aborted]: out of memory; can not reallocate 95683558 TIA. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root']
don't know if you all know this or not but it helps me when I can't find what I need (which is often) on a particualr site: at google.com's input field: __ | site:cvshome.org error messages |and hit enter --- site: is a command and so it searches for the keywords at the site specified You will be amazed at the jewels of wisdom a org/com keeps hidden from it's users unintentionally... - Original Message - From: Greg A. Woods [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 10, 2001 9:33 PM Subject: Re: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root'] [ On Tuesday, July 10, 2001 at 16:40:04 (+0200), Pascal Bourguignon wrote: ] Subject: Re: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root'] Well, you're not alone having difficulties with the CVS manual. Either a good number of CVS users like me are dumb or indeed there's a problem with the manual. I think part of the problem is with this word read. It's been quite a long time since I sat down and actually read the manual. I tend to use the 's' key in info a lot, and that can result in worse side-tracking and unapplicable references than typing sex into Google. I think that if people (including even me!) actually _read_ the manual then there would be far less complaint. Texinfo manuals are, after all, generally written in such a way as to lend themselves far more to being read than to being used as a reference, and the CVS manual is no different in this respect. I still use (not read, exactly) the old troff manual sometimes simply because it's a better reference despite being effectively deprecated and out-of-date. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ 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: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root']
[ On Monday, July 9, 2001 at 20:22:56 (-0700), David Taylor wrote: ] Subject: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root'] When someone who has long chanted RTFM! as the panacea for countless ills can't find what he wants in the manual (and is thus led to proclaim its absence a failing of the manual), though it exists in the manual...we can all agree that there is a problem here. Oh, I hope I've never really claimed the fine manual was the only panacea for all ills! ;-) I recant if I did! Of course my inability to find something in the manual isn't necessarily due to a failing in the manual either. My self analysis was an attempt to discover why *I* had a problem finding a particular reference. Whether my experiences would match those of anyone else is a very different question, the answer to which is left as an excercise for the reader! ;-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root']
[EMAIL PROTECTED] (Greg A. Woods) wrote: [ On Monday, July 9, 2001 at 20:22:56 (-0700), David Taylor wrote: ] Subject: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root'] When someone who has long chanted RTFM! as the panacea for countless ills can't find what he wants in the manual (and is thus led to proclaim its absence a failing of the manual), though it exists in the manual...we can all agree that there is a problem here. Oh, I hope I've never really claimed the fine manual was the only panacea for all ills! ;-) I recant if I did! Of course my inability to find something in the manual isn't necessarily due to a failing in the manual either. My self analysis was an attempt to discover why *I* had a problem finding a particular reference. Whether my experiences would match those of anyone else is a very different question, the answer to which is left as an excercise for the reader! ;-) Well, you're not alone having difficulties with the CVS manual. Either a good number of CVS users like me are dumb or indeed there's a problem with the manual. -- __Pascal_Bourguignon__ (o_ Software patents are endangering () ASCII ribbon against html email //\ the computer industry all around /\ and Microsoft attachments. V_/ the world http://lpf.ai.mit.edu/ 1962:DO20I=1.100 2001:my($f)=`fortune`; http://petition.eurolinux.org/ -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT d? s++:++(+++)++ a C+++ UB+++L$S+X$ P- L+++ E++ W++ N++ o-- K- w-- O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+) DI+++ D++ G++ e+++ h+(++) r? y---? UF --END GEEK CODE BLOCK-- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root']
[ On Tuesday, July 10, 2001 at 16:40:04 (+0200), Pascal Bourguignon wrote: ] Subject: Re: RTFM? [ was Re: cvs [commit aborted]: cannot commit files as 'root'] Well, you're not alone having difficulties with the CVS manual. Either a good number of CVS users like me are dumb or indeed there's a problem with the manual. I think part of the problem is with this word read. It's been quite a long time since I sat down and actually read the manual. I tend to use the 's' key in info a lot, and that can result in worse side-tracking and unapplicable references than typing sex into Google. I think that if people (including even me!) actually _read_ the manual then there would be far less complaint. Texinfo manuals are, after all, generally written in such a way as to lend themselves far more to being read than to being used as a reference, and the CVS manual is no different in this respect. I still use (not read, exactly) the old troff manual sometimes simply because it's a better reference despite being effectively deprecated and out-of-date. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
[ On Monday, July 9, 2001 at 01:03:36 (-0400), Lenny Foner wrote: ] Subject: cvs [commit aborted]: cannot commit files as 'root' In that time, you've come across as basically a reactionary force, in the original meaning of that term---in other words, just about any change to CVS has launched you on a crusade to preserve the One True Original Implementation, even in the face of lots of people who might rather it behaved otherwise. You're obviously not paying attention to what I'm writing. Please try again. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
You know.. something I've noticed... On one side there are the people who will never read the manual, but will expect the mailing list, forums, et. al. to answer every little question they have whether it's I can't get my webserver to run cgi scripts or how do I import a new project or I don't understand my algebra homework. On the other side... the manual just plain sucks. It's confusing, poorly organized, badly written, and as you pointed out.. it's sorely lacking a full list of error messages. In short.. it needs to be rewritten very badly. I have a hard time being upset at someone who doesn't RTFM the cvs manual because it's painful to read. Daniel ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Attention CVS Zealots (was Re: cvs [commit aborted]: cannot commit files as 'root')
[EMAIL PROTECTED] wrote: cowed by the thought of having Greg yell at them for days that they're unwilling to start, or if I'm told that no such patch will be accepted to CVS, then it will die here. I generally ignore rants, especially from Mr. Greg Woods. Greg - you're obviously very smart, and very well-informed about CVS, networking and general computing - but STFU already. You have become NOISE. Are you this boorish off-line? I want to see CVS improve and will gladly host / administer any such efforts. In fact, I have planned to do so for quite some time in the context of my plans for freepository. Anyone who desires to improve CVS - behavior, error messages, user interface, bells, whistles or documentation - please reply directly to me off this list. I have the time, desire, knowledge, hardware, and network infrastructure to make this happen. Bullies and weasels Need Not Apply. -- John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
Greg A. Woods writes: It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with links to nodes containing their explanations. Excuse me? http://cvshome.org/docs/manual/cvs_21.html#SEC181 -Larry Jones What this games needs are negotiated settlements. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
Has anyone considered coding a little helper, say, an animated paper clip, that'll help people through the index of the manual? All right! Who threw the tomato? Regards, Mike Klinke - Original Message - From: Larry Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 09, 2001 10:40 AM Subject: Re: cvs [commit aborted]: cannot commit files as 'root' | Greg A. Woods writes: | | It isn't even in the manual, as far as I can see. That's maybe the | worst failing of the manual -- there's no (even partial) list of the | error messages in one place with links to nodes containing their | explanations. | | Excuse me? | | http://cvshome.org/docs/manual/cvs_21.html#SEC181 | | -Larry Jones | | What this games needs are negotiated settlements. -- Calvin | | ___ | 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: cvs [commit aborted]: cannot commit files as 'root'
[ On Monday, July 9, 2001 at 11:40:28 (-0400), Larry Jones wrote: ] Subject: Re: cvs [commit aborted]: cannot commit files as 'root' Greg A. Woods writes: It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with links to nodes containing their explanations. Excuse me? http://cvshome.org/docs/manual/cvs_21.html#SEC181 Ah, so there is! Sorry! Maybe what the manual needs more than anything else is a top-level complete table of contents listing every node in the menu (much like the The Detailed Node Listing in the Emacs manual and so many other wonderful texinfo-based manuals). The texinfo index is wonderful, and all, but it's just an index. I've come to expect the detailed listing and given there's no obvious way to restrict a search in 'info' to the current node, or to headings only, it's hard to find a node that you don't know exists. I don't know if there are any existing tools to help build the menu and detailed node listing, or not... -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: cannot commit files as 'root'
Anyone? I get the following message attempting to make a commit locally on the CVS server: cvs [commit aborted]: cannot commit files as 'root' $CVSROOT is properly set. All is fine if I switch to another user. File permissions in the repository look good too. Is this an intended security feature ... or am I just being stupid again? == Matthew Von-Maszewski [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
[ On Sunday, July 8, 2001 at 11:16:40 (-0400), Matthew Von-Maszewski wrote: ] Subject: cvs [commit aborted]: cannot commit files as 'root' Is this an intended security feature ... or am I just being stupid again? VERY intended! -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
Matthew Von-Maszewski writes: cvs [commit aborted]: cannot commit files as 'root' [...] Is this an intended security feature ... or am I just being stupid again? It's an intended feature, but it has more to do with maintaining accountability than security. Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: cannot commit files as 'root'
Date: Sun, 8 Jul 2001 15:26:59 -0400 (EDT) From: [EMAIL PROTECTED] (Larry Jones) Matthew Von-Maszewski writes: cvs [commit aborted]: cannot commit files as 'root' [...] Is this an intended security feature ... or am I just being stupid again? It's an intended feature, but it has more to do with maintaining accountability than security. Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. You know, given how often people ask this question, maybe some paragraph of your response here should be put INTO THE ERROR MESSAGE ITSELF. Yeah, I know, I know, everyone will say that's why you're supposed to read the manual!, but it's obvious that either (a) people aren't reading it well enough, or (b) it's a little too buried. So why not actually spell the entire thing out in the message? It's not like brevity is required in these things. I'd say you should just take everything after the first sentence above (e.g., starting at Since root is usually...) and just add it to the error message. If that were done, some large percentage of FAQs would stop being asked. If that were done to many of the other common screwups, many more people could also be instantly enlightened, instead of asking the list. It speeds them up (they don't have to (a) try to find the message in th emanual, or (b) compose a message, send it, and wait for a reply), and it might even make life easier for people who are using CVS whose native language isn't English and who aren't using some localized copy---after all, the more explanation there is, the more likely that some subportion of it will be intelligible enough that the user will understand it. [My favorite example of this---and it's even for a native English speaker!---is the compiler error message saying FOO is multiply defined, which invariably causes some subset of those reading it to say, What in the world does multiplication have to do with what Im doing? It -should- say, FOO is defined more than once or FOO is defined multiple times---just a teeny bit of additional prose can do wonders.] My basic point here is that, industry-wide, far too many error messages are far too terse. They should include paragraphs of prose, pointers to manual sections, URLs for further clarification---and probably all -three- of them. Why not? After all, we're no longer using 300 baud teletypes where a long error message takes a minute to sit through. Nor does it matter if the executable is 10K larger because the error messages actually tell you what's wrong---not in an era of 1G OS's and 10M applications... Thanks for listening... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs [commit aborted]: cannot commit files as 'root'
su to root worked like a champ. Thanks for the work-around. Matthew -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 08, 2001 3:27 PM To: Matthew Von-Maszewski Cc: [EMAIL PROTECTED] Subject: Re: cvs [commit aborted]: cannot commit files as 'root' Matthew Von-Maszewski writes: cvs [commit aborted]: cannot commit files as 'root' [...] Is this an intended security feature ... or am I just being stupid again? It's an intended feature, but it has more to do with maintaining accountability than security. Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
Matthew Von-Maszewski writes: su to root worked like a champ. Thanks for the work-around. Perhaps I understated things a bit in my original response. There *are* security concerns with committing as root -- be very sure you know what you're doing. Even better, just don't do it. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
[ On Sunday, July 8, 2001 at 16:00:55 (-0400), Lenny Foner wrote: ] Subject: cvs [commit aborted]: cannot commit files as 'root' You know, given how often people ask this question, maybe some paragraph of your response here should be put INTO THE ERROR MESSAGE ITSELF. Well actually I would have thought the message was already very very clear all by itself -- if maybe a bit terse for anyone with English as a second language. It does, after all, say exactly what it means. Maybe if it said You, whomever you are, cannot commit files as 'root'! (complete with the explanation mark :-) That's not a real suggestion though -- CVS error messages should remain as stable as possible so as to facilitate ease of maintenance of wrapper and front-end programs. I think what maybe surprises people about this is that usually 'root' can do anything and usually error messages say you must be root to Obviously though a source code control system has different security requirements than a filesystem. Yeah, I know, I know, everyone will say that's why you're supposed to read the manual!, but it's obvious that either (a) people aren't reading it well enough, or (b) it's a little too buried. It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with links to nodes containing their explanations. My basic point here is that, industry-wide, far too many error messages are far too terse. They should include paragraphs of prose, pointers to manual sections, URLs for further clarification---and probably all -three- of them. Why not? Why? What a waste of space, energy, resources, time, effort, etc.! All that's really necessary is that the documentation contain descriptions of the error messages. With 'info' documentation the searching for the meaning is extremely simple. I really rather dislike execessive verbosity in error messages. Specifically for CVS though error messages should be kept as stable as possible and short enough that when fully formatted with an average filename they don't exceed 80 characters in length. After all, we're no longer using 300 baud teletypes where a long error message takes a minute to sit through. Nor does it matter if the executable is 10K larger because the error messages actually tell you what's wrong---not in an era of 1G OS's and 10M applications... Size and speed aren't everything (though they're certainly still very very important -- far more important than you seem to think!). Maintenance is also incredibly important. I think it's far better to have very good documentation and to keep it up-to-date with lists and descriptions of error messages rather than to have to maintain the same text in both the code and the documentation (or come up with some convoluted scheme to try to merge one from the other). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [commit aborted]: cannot commit files as 'root'
Date: Sun, 8 Jul 2001 18:28:50 -0400 (EDT) From: [EMAIL PROTECTED] (Greg A. Woods) [ On Sunday, July 8, 2001 at 16:00:55 (-0400), Lenny Foner wrote: ] Subject: cvs [commit aborted]: cannot commit files as 'root' You know, given how often people ask this question, maybe some paragraph of your response here should be put INTO THE ERROR MESSAGE ITSELF. Well actually I would have thought the message was already very very clear all by itself -- if maybe a bit terse for anyone with English as a second language. It does, after all, say exactly what it means. No, it only says that you can't. It doesn't explain WHY, which was precisely the question that was asked. Nor, apparently, does it help anyone who ever gets it---they say, Yeah, so, I'm root. What's the big deal? And then (a) they waste their time asking the list, and (b) they waste all -our- time reading their question, and (c) they waste a few peoples' time who answer them. Seems suboptimal to me... Maybe if it said You, whomever you are, cannot commit files as 'root'! (complete with the explanation mark :-) That doesn't help the users, whose immediate next question is, why not? That's not a real suggestion though -- CVS error messages should remain as stable as possible so as to facilitate ease of maintenance of wrapper and front-end programs. You're kidding, right? You're actually arguing that error messages must remain fixed for all time because someone might have based a wrapper on them? Whatever happened to the concept of exit codes? Whatever happened to the concept of the localization of all text emitted by a program for the user's native language? Whatever happened to any pretense of design, not to mention professionalism? If that's -really- the concern, then I submit that a much more stable mechanism would be to number all the error messages uniquely, and emit that number (perhaps surrounded by some sequence of characters not ever used elsewhere in error messages---though be careful of filenames! probably it needs to be ina known location, like the start) along with the error text. And, of course, the easiest way to do that would be to put all the error messages in a big enumeration, which guarantees no duplicated numbers (because it's the compiler assigning the numbers), and makes internationalization simply a matter of translating the messages that appear in that table---which is probably in a single file. This isn't rocket science---it's how any number of programs are actually written. Obviously, you have to make sure that nobody ever inserts a new message in the middle and upsets the numbers, but hey, that's easy enough to enforce---in sanity.sh if necessary. (Or, you move away from numbers entirely, and use unique strings---checked by whatever routine builds the table to -guarantee- that they are, in fact, unique---hence avoiding any ordering at all. This is how VAX/VMS did it, so typical error messages that looked like DCL-F-NOFILE, no such file FOOBAR and you know what emitted the message [DCL], how bad it was [fatal], and had a unique string if you really wanted to search for it in a logfile [NOFILE].) Hence, a typical CVS error message might instead look like: ##CVS-Error 23##: cvs [commit aborted]: cannot commit files as 'root' Since root is usually a shared account, CVS won't allow you to commit as root unless it can figure out who you really are. Logging in as yourself and then su'ing to root will usually allow CVS to figure out who you are, but logging in as root won't. If you're sure you want to be able to commit as root, see CVS_BADROOT in src/options.h. For more information, see section 23.4.5 of the manual, or http://foo/bar.html. Wrappers can search for the ##CVS-Error 23##. Users can ignore that part, though they can use it in bug reports as a shorthand. But users -do- get something that actually explains what they did wrong, exactly where and when they need it, and without forcing a shift of attention. Those attention shifts are very costly in terms of productivity. I think what maybe surprises people about this is that usually 'root' can do anything and usually error messages say you must be root to Obviously though a source code control system has different security requirements than a filesystem. In this particular case, you may (or may not) be correct about what it is that surprises people. I'm making a more-general argument than just this particular error message, of course. Yeah, I know, I know, everyone will say that's why you're supposed to read the manual!, but it's obvious that either (a) people aren't reading it well enough, or (b) it's a little too buried. It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with links to nodes containing
Re: cvs [commit aborted]: cannot commit files as 'root'
[ On Sunday, July 8, 2001 at 19:27:07 (-0400), Lenny Foner wrote: ] Subject: cvs [commit aborted]: cannot commit files as 'root' No, it only says that you can't. It doesn't explain WHY, which was precisely the question that was asked. Well of course not! RTFM! Nor, apparently, does it help anyone who ever gets it---they say, Yeah, so, I'm root. What's the big deal? And then (a) they waste their time asking the list, and (b) they waste all -our- time reading their question, and (c) they waste a few peoples' time who answer them. Seems suboptimal to me... You'll never eliminate RTFM answerable questions, not even if you put the whole stinking manual right into the code so every message is as verbose as humanly possible. Maybe if it said You, whomever you are, cannot commit files as 'root'! (complete with the explanation mark :-) That doesn't help the users, whose immediate next question is, why not? The immediate response of any sane person who asks such a question should be to RTFM! That's not a real suggestion though -- CVS error messages should remain as stable as possible so as to facilitate ease of maintenance of wrapper and front-end programs. You're kidding, right? Nope, not at all. Not one iota. That's a very very serious concern. I dare you to write a front-end to CVS (as it is today) and say otherwise! You're actually arguing that error messages must remain fixed for all time because someone might have based a wrapper on them? No, I'm not saying that either -- I'm saying they must not change without due cause. Whatever happened to the concept of exit codes? What about them? They serve an entirely separate purpose. Whatever happened to the concept of the localization of all text emitted by a program for the user's native language? What indeed! Do you have patches to implement this feature in CVS? Whatever happened to any pretense of design, not to mention professionalism? You should learn some more about the history of CVS and its development. I'm sure such knowledge will enlighten you significantly! ;-) If that's -really- the concern, then I submit that a much more stable mechanism would be to number all the error messages uniquely, and emit that number (perhaps surrounded by some sequence of characters not ever used elsewhere in error messages---though be careful of filenames! This is a viable scheme, but it would take quite some doing to make CVS (as we know it today) implement it. UNIX System V took a similar approach, though I don't know exactly how far they got. Sounds like sanity.sh should be amended to do a grep for every error message through the manual and at least make sure that it appears -somewhere-. Hmm I think it would be easier to analyse the code and create REs from the printf format strings At least then you know where the variable bits of the messages are, and even what type of data to expect in those places Such a tool would have much wider application than just CVS, of course! Why? What a waste of space, energy, resources, time, effort, etc.! Because one implementor's effort saves n thousand people's time, that's why. I think you vastly under-estimate the needs of the maintainer. This is no small problem we're talking about here! I would submit that it simply cannot ever succeed without at least partial automation, and of course such a drastic change would require a very significant amount of up-front work, even if one did draw upon existing practice (eg. have a look at the code in Postfix). I know of what I speak -- I've been around this block more than once myself! Why force the user through an extra step? He's already staring at the message. Why not help him to understand what he's looking at? Why force an expert user (not to mention a front-end driver program) through all the extra verbiage? Why not help the user learn to become an expert user? I really rather dislike execessive verbosity in error messages. Is telling the user what he did wrong, and why, excessive? Yes, absolutely. A simple error number is insufficient except for the most expert user (or front-end program). An error message must give just enough information to provide context and memory/search clues, and absolutely no more. We're not talking about some kind of fancy GUI-driven DWIM application here! If you want all that extra crud all the time then please put it only int he fancy GUI DWIM thing, not in the underlying _tool_. You sound like you're saying that all CVS error messages should simply be ?, like a certain well-known text editor from the early 70's, when memory was many cents/bit. Or perhaps they should just be abend 34117; after all, that's what the manual is for, right? There was a significant UI advantage to that scheme, but of course it can only be taken so far! ;-) Inscrutible error messages may be -your- preference, Now just hold on one
cvs [commit aborted]: cannot commit files as 'root'
Greg. Greg, Greg, Greg. I've been watching your traffic on info-cvs since about August 1996. That's over 100 meg of traffic. Of course, not all of it is yours. In that time, you've come across as basically a reactionary force, in the original meaning of that term---in other words, just about any change to CVS has launched you on a crusade to preserve the One True Original Implementation, even in the face of lots of people who might rather it behaved otherwise. You've generally shouted down many attempts to change CVS via bluster, zillions of increasingly-inflammatory messages (in which the count of exclamation marks increases exponentially over time), and apparently having more time than anyone else who cares to shout ever more loudly about what -you- want CVS to be. People who don't have time to spend arguing with you simply leave. This is a common occurrence in all sorta of fora. Various experiments in self-governance in MUDs, for example, have failed by being taken over by people who have no lives. Such people spend more time shouting than people with better things to do, and win by driving everyone reasonable away. This effect has been documented by numerous academic papers which look at the sociology and anthropology of online environments. On this list, -you- seem to have that role. I'm going to respond -just once- to your latest scream, and then I'm going to abandon this thread no matter what you say. I don't have the time. If someone informs me that patches to make CVS easier to use would be accepted, I may well write some. Other people might, too. (Obviously, I'd be more than happy to participate in a discussion of how such a patch should be designed.) Of course, the more likely outcome is that any patches intended to make life easier for the users, no matter how rational, will simply be shouted down by you. Thus, there -aren't- any such patches, because nobody wants to waste their time writing them when you'll try to shout them off the stage. This is the sort of behavior that leads to forking the code in order to make progress. Perhaps this should have happened years ago. Of course, maybe the most productive approach would be to create the Greg fork, and the fork everyone else uses; that avoids having two large but splintered groups of users, as seems to have happened with the *BSD forks of various things already. I should note that I am -not- the first to suggest a Greg fork; this alone might give one pause. Given your repeated screams of RTFM!, I must conclude that you hate CVS' users and wish to punish them. (It's especially ironic in this case, since you've said yourself that this particular error message never got documented in the M to begin with.) I don't share that viewpoint. And, given the message traffic on this list, I'm willing to believe that the people who write here asking questions don't share that viewpoint, either. And I'll bet that those few selfless individuals who seem to spend a great deal of time answering their questions don't share that viewpoint, either, and would rather that users could be made more independent. What's wrong with empowering the users? Now, let me address your particular points. As I see it, they are all strawmen, but you need to have them in order to bluster more effectively: o You've said quite clearly that making things easier for users is inherently bad, e.g., that they must not be enlightened through the actual error messages, but merely given -just- enough information to be able to find out something about the error in the manual. This seems an extremely curious attitude; I wonder if it is widely shared. o You've spent lots of bluster talking about time and resources, but have failed to actually mention what resources those are. I contend that those resources break down into an insignificant amount of memory and load-time (and you did not refute those), some amount of CVS developer time, and some amount of time to make sure that front-ends can parse the results. It is my contention that the developer-time required to dramatically improve the situation (see below) is insignificant when compared to the users' time, and the time of those who read this list, that is wasted by not doing so. o You claim that front-ends cannot handle more-useful documentation, but that's clearly a strawman argument. As I demonstrated, it wouldn't be hard to embed some unique identifier into -every- message that CVS emits, and front ends can trivially look for it. o You claim that I must clearly be inexperienced, both as a programmer and in CVS internals, to have made the assertions I did. Having been a programmer since 1973 and the days of the PDP-8, I can assure you that I'm not. I've done work in speech recognition. I've helped build Ada compilers. I was a systems programmer for many years on Lisp Machines. I've done more communications-related programming than I can remember. I've built commercial expert systems in a
cvs [commit aborted]: received broken pipe signal
Hi, when im committing a _large_ tree in my initial checkin, i frequently get this error, Does this have something to do with my OS (HPUX 11) or is it a bug? Is this serious or can I just restart my commit? cvs [commit aborted]: received broken pipe signal Thanx. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: received broken pipe signal
Jelle Boomstra writes: when im committing a _large_ tree in my initial checkin, i frequently get this error, Does this have something to do with my OS (HPUX 11) or is it a bug? Is this serious or can I just restart my commit? cvs [commit aborted]: received broken pipe signal That probably means that you're running out of memory or temporary file space. (If you're using client/server CVS, the problem would be on the server system.) It's probably safe to just restart the commit, but it would be better to fix the problem. -Larry Jones Monopoly is more fun when you make your own Chance cards. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[commit aborted]: end of file from server
Let me try again, i am getting the following message trying to use verifymsg functionality: cvs commit -m "Enter Defect Number:444" crazy.cpp cvs [commit aborted]: end of file from server (consult above messages if any) any ideas what it means?
cvs [commit aborted]: cannot commit files as 'root'
Hello ! I'm a beginner user of CVS and I don't know to resolve this error.I've setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've import a project but I can't commit the work. The error received is : cvs [commit aborted]: cannot commit files as 'root' What should I do ? Thanks ! Crosby
Re: cvs [commit aborted]: cannot commit files as 'root'
Don't run cvs as root. donald On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: Hello ! I'm a beginner user of CVS and I don't know to resolve this error.I've setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've import a project but I can't commit the work. The error received is : cvs [commit aborted]: cannot commit files as 'root' What should I do ? Thanks ! Crosby
Re: cvs [commit aborted]: cannot commit files as 'root'
On Monday 3 April 2000, at 16 h 42, the keyboard of Crosby [EMAIL PROTECTED] wrote: I'm a beginner user of CVS and I don't know to resolve this error.I've setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. This is certainly one of the most awful errors an Unix user can make.
Re: cvs [commit aborted]: cannot commit files as 'root'
Yes , this is the easyest solution but on my work station I'm always logged as root. The CVS server is working on our local server . I use ssh to access the remote repository.It's possible to make a map On Mon, 03 Apr 2000, you wrote: Don't run cvs as root. donald On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: Hello ! I'm a beginner user of CVS and I don't know to resolve this error.I've setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've import a project but I can't commit the work. The error received is : cvs [commit aborted]: cannot commit files as 'root' What should I do ? Thanks ! Crosby
Re: cvs [commit aborted]: cannot commit files as 'root'
Dear friends , I use my Linux from a long time and most of time like a root . If you (mr. Donald) give commands which are dangerous for your system is your problem. I know what I'm doing when press Enter after a command. For my question I don't receive a right answer. I don' t think it's a big mistake to make some changes to a project logged as root. I have thinking to a way to map the local user ( root ) to another user on server . Maybe this is possible but nobody give me a solution. Of course the easyest (to login as other user) was in my mind but I look after other solution. Anyway thanks for your (help) ! Crosby On Mon, 03 Apr 2000, you wrote: Well to put it bluntly, it's at *best* idiotic to run as root for day to day usage of unix. Your asking for a world of hurt when you do a 'rm -rf /' accidently, or any number of other things that root can do that will *KILL* your system. Change the way you are working. There is a very good reason that cvs doesn't let you commit as root, which is the very same reason that you shouldn't run as root unless you have to. Running as root all the time is like holding a gun to your head, spinning the chambers and then pulling the trigger every time you input a command. You are going to burn yourself ( or at least put a very large hole in your head, metaphorically speaking of course ) donald On Mon, Apr 03, 2000 at 05:58:43PM +0300, Crosby wrote: Yes , this is the easyest solution but on my work station I'm always logged as root. The CVS server is working on our local server . I use ssh to access the remote repository.It's possible to make a map On Mon, 03 Apr 2000, you wrote: Don't run cvs as root. donald On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: Hello ! I'm a beginner user of CVS and I don't know to resolve this error.I've setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've import a project but I can't commit the work. The error received is : cvs [commit aborted]: cannot commit files as 'root' What should I do ? Thanks ! Crosby
Re: cvs [commit aborted]: cannot commit files as 'root'
Crosby writes: I use my Linux from a long time and most of time like a root . If you (mr. Donald) give commands which are dangerous for your system is your problem. I know what I'm doing when press Enter after a command. If you insist on being stupid (and it's your right to do so), you can edit src/options.h to remove the #define of CVS_BADROOT. -Larry Jones Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -- Calvin
Re: cvs [commit aborted]: cannot commit files as 'root'
On Monday, April 3, Crosby wrote: Dear friends , I use my Linux from a long time and most of time like a root . If you (mr. Donald) give commands which are dangerous for your system is your problem. I know what I'm doing when press Enter after a command. For my question I don't receive a right answer. I don' t think it's a big mistake to make some changes to a project logged as root. I have thinking to a way to map the local user ( root ) to another user on server . Maybe this is possible but nobody give me a solution. Of course the easyest (to login as other user) was in my mind but I look after other solution. Anyway thanks for your (help) ! Ok, there is a way. However, I hesitate to show you that way, since you are "root", obviously a power-user, and can't find the method to do so by yourself... Anyhow, using the following method, I've been able to do what you wish: export CVS_RSH=ssh export [EMAIL PROTECTED]:/cvsroot PS: Do you know *WHY* cvs will not let you run things as root? --Toby.
Re: cvs [commit aborted]: cannot commit files as 'root'
On Monday, April 3, Donald Sharp wrote: There is no right answer. cvs was designed to not allow the root user to do cvs commands. This has to do with the philosophy about why you shouldn't run as root unless you have to. It also goes into the level of trust that you are willing to let one 'root' user have on another machine. If you are so set on running as root go into the source and remove the check to see who you are running as, because obviously you know best In any event you will be running a unsupportable version of the cvs source base I may be wrong, but I believe there are other reasons that 'root' is not allowed to use cvs. I believe that they involve locking and such. --Toby.
Re: cvs [commit aborted]: cannot commit files as 'root'
on 4/3/00 12:40 PM, Crosby at [EMAIL PROTECTED] wrote: I use my Linux from a long time and most of time like a root . If you (mr. Donald) give commands which are dangerous for your system is your problem. I know what I'm doing when press Enter after a command. Generally accepted practices, such as not doing normal root as root, are generally accepted for a reason. No matter how smart you are. -- Tracy Snell Orlando Office 21st Century Telecom [EMAIL PROTECTED]
Re: cvs [commit aborted]: cannot commit files as 'root'
On Mon, Apr 03, 2000 at 16:42 +0300, Crosby wrote: I'm a beginner user of CVS and I don't know to resolve this error.I've setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. The software is trying to tell you something (and the handbook did so, too -- if you would care to have a look there). DON'T work as root if you're not doing _any_ administrative task. Running X or reading mail or doc or doing development all has nothing to do with "priviledges needed". You shoot into your own foot -- don't do that! What should I do ? Take the advise to work as a usual user, just like anyone else does. 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.
