CVS Server too slow???
Submitter-Id: net Originator: Kursat Ince Organization: net Confidential: no Synopsis: inetd stops cvs servering Severity: critical Priority: medium Category: cvs Class: support Release: cvs-1.10.6 Environment: System: Linux Guvercin 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown Architecture: i586 Description: I setup a cvs server (for remote access) on Guvercin. Every thing is just fine. But when I started using cvscheck, a freely available shell script, inetd stops serving and refuses connections. I know cvscheck does too many cvs requests and may be my computer or the server is slow. How-To-Repeat: * Setup a cvs server * use cvscheck from the remote * inetd will refuse cvs connections (check log messages) Fix: Don't know. The original message was received at Wed, 8 Mar 2000 11:10:03 +0200 from root@localhost - The following addresses had permanent fatal errors - [EMAIL PROTECTED] - Transcript of session follows - ... while talking to mescaline.gnu.org.: MAIL From:[EMAIL PROTECTED] SIZE=930 501 [EMAIL PROTECTED]... Sender domain must exist 501 [EMAIL PROTECTED] Data format error Reporting-MTA: dns; Guvercin.tis.havelsan.com.tr Arrival-Date: Wed, 8 Mar 2000 11:10:03 +0200 Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.5.2 Remote-MTA: DNS; mescaline.gnu.org Diagnostic-Code: SMTP; 501 [EMAIL PROTECTED]... Sender domain must exist Last-Attempt-Date: Wed, 8 Mar 2000 11:10:40 +0200 Submitter-Id: net Originator: Kursat Ince Organization: net Confidential: no Synopsis: inetd stops cvs servering Severity: critical Priority: medium Category: cvs Class: support Release: cvs-1.10.6 Environment: System: Linux Guvercin 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown Architecture: i586 Description: I setup a cvs server (for remote access) on Guvercin. Every thing is just fine. But when I started using cvscheck, a freely available shell script, inetd stops serving and refuses connections. I know cvscheck does too many cvs requests and may be my computer or the server is slow. How-To-Repeat: * Setup a cvs server * use cvscheck from the remote * inetd will refuse cvs connections (check log messages) Fix: Don't know.
http://www.sourcegear.com/CVS/Dev/patches/http
Hi Andy Jim Co, I applied the proxy patch to the cvs-1.10.8 source. However, our http proxy server requires users to login and I do not see anywhere in the source patch where this is handled. Has anyone already addressed this issue and provided a fix for authenticating users through the http proxy first? Any ideas greatly appreciated. TIA, Robert Nader mailto:[EMAIL PROTECTED] System/Client Support Tel: +966-3-8733687 Geophysical Data Processing Division Fax: +966-3-8730054 Exploration Operations Department ARAMCO, Dhahran, Saudi Arabia
Enhancement suggestion: CVS rename
Hello all, I'm using CVS 1.10 and I am quite happy with it; however there is one very important feature missing: CVS rename The manual describes some workarounds, but these are quite unsatisfactory; I suspect many to what I have been doing, just delete and add it at the new location and loosing convenient access to the history. I am very fond of the simple architecture of cvs/rcs, i.e. every file contains all the information, you don't need any master database stored somewhere. In my mind it is critical to maintain this feature after adding the rename feature. To implement rename a name-location fields needs to be added to the standard revision information (author, date, state, log). This fields can be added in several ways: * use an existing fields (i.e. author). * use special symbol (dirty !?) * add a new fields in such a way that the currrent rcs parser would ignore, i.e. not complain about - maybe not possible !? Making the rcs file format backwards incompatible should be avoided if at all possible. Modifications: 1. Add name-location field that is associated with every revision (like author). The location fields would be a path name starting from CVS_ROOT - it would not include CVS_ROOT path prefix = easy to relocate repository. * the location in the latest revision would be in sync with cvs repository location * the name in the latest revision would also be the name of the file in the cvs repository 2. cvs checkout: find revision check if name-location field exists, if so check file out to that location and under that name 3. cvs rename insert pending name and location change 4. cvs commit (this should be integrated in rcs) move the updated file to the new name-location (often no change) The design has two important attributes: * The cvs repository will look the same for the main branch for this new cvs and the current one. This means that when a user looks at the repository, he sees the most recent layout - which is natural. * All information is still stored in one file only. - - - - - I would like to contribute to this change, but I think there are some cvs-gurus who are far more adept to do it - at least I have some learning to do; maybe in a few months time I will be ready. To me this is a most-wanted feature because without it you can't reorganize your code unless loosing history (the workaround is ugly) and so many probably don't do it ! Best regards, Bergur Ragnarsson ICELAND
Re: cvs up -C bug(s)
Noel L Yap writes:
I'm running client/server cvs-1.10.8 (with some "cvs edit" patches). The
command ("cvs up -C file") works fine if noone has yet checked in "file" (after
the local copy had been checked out). However, it doesn't work in the following
situation:
user1user2
1. cvs co module cvs co module
2. cd modulecd module
3. # modify file # modify file
4. cvs ci file
5. cvs up -C file
Upon step 5, user1 gets:
(Locally modified loginfo moved to .#file.1.1)
cvs [server aborted]: cannot open loginfo for copying: No such file or directory
If you use a local repository rather than client/server you get:
retrieving revision 1.1
retrieving revision 1.2
Merging differences between 1.1 and 1.2 into file
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in file
C file
You get similar results if the file has a sticky tag or date and you
update to a different revision.
In my opinion, you should never get merging. If you specify a
particular revision or date, that's the version you should get and it
should be sticky. Otherwise, if there's already a stick tag or date on
the file and you don't specify -A, you should get the sticky revision.
Otherwise, you should get the head version (with no sticky revision). I
don't have a clue as to what -j should do in combination with -C.
-Larry Jones
From now on, I'm devoting myself to the cultivation of
interpersonal relationships. -- Calvin
