CVS patch for unedit -e
To enforce automatic procedure for controling changes I need as an administrator the possibility to remove somebody's edit. Unfortunately in version 1.11.6, we are using, option cvs unedit -e is not implemented. On info-cvs list I found, that there is a patch introducing it. I cannot find it though. I searched in sourceforge.net, but without any results (suggested RCVS project is not accessible). I have also tried to point my browser to the link attached in one of replies (dated 2001) but I got message: Permission: User Not Found: Only members of this project have permission to view this page (you are not listed as a member of this project) Could you please give me information where I can find the patch (implementing commands unedit -e and edit -c), or if it's not very problematic could you please send it. Regards, Krzysztof Górbiel ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
filename created independently by second party
Hello all. CVS 1.11 It's probably my fault - I was trying to do a final import to prepare for our version control strategy going live. What I didn't remember is that, with my developer's hat on, I had created some new files and done a cvs add in my local working copy. And to test those files I had to put them in the general code area. So they got imported too. So when I went to commit the files back in my local working copy I got filename created independantly by second party. I couldn't merge away the conflict. In the end I just cvs remove'd the version from the import. My question is, was there a better, cleaner way out of that conflict? Shouldn't a cvs update have merged the differences between the two versions? Andy Jones Tapestry Software ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Error commit_prep
Hi I have a little problem with cvs 1.11 in Suse Linux. When I have finished a commit, then it appears in my shell the next error messages: sh: commit_prep.in: command not found sh: log_accum.in: command not found But It seems that the commit runs fine. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Error commit_prep
Juan D Dominguez Caravaca writes: I have a little problem with cvs 1.11 in Suse Linux. When I have finished a commit, then it appears in my shell the next error messages: sh: commit_prep.in: command not found sh: log_accum.in: command not found But It seems that the commit runs fine. You may want to consider upgrading: 1.11 is ancient, 1.11.8 is the current release. Check your CVS administrative files for references to the above commands -- they're probably in commitinfo and loginfo. You should not be trying to run the *.in files, they're input to autoconf which then generates commit_prep and log_accum, which are the files you want to run. You may want to add explicit paths to the entries in the administrative files so that you don't have to have them in your $PATH. -Larry Jones Well of course the zipper's going to get stuck if everyone stands around WATCHING me! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: filename created independently by second party
Andy Jones writes: So when I went to commit the files back in my local working copy I got filename created independantly by second party. I couldn't merge away the conflict. In the end I just cvs remove'd the version from the import. My question is, was there a better, cleaner way out of that conflict? Temporarily rename your local file; do a cvs rm on the original name to unadd it; update to get the file from the repository; check to be sure that you really want your local file instead; then rename your local file back, replacing the one you just got. Shouldn't a cvs update have merged the differences between the two versions? As far as CVS knows, the two file have nothing whatsoever to do with each other. Without a common ancestor, there's nothing to merge -- you'd just have one big conflict with the entire contents of both files, so there's no point in even trying. -Larry Jones Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: filename created independently by second party
::slaps heel of hand to forehead:: That's what comes of being the CVS administrator *and* a programmer: I kept thinking it was a problem for administrator-me. Thank you. On Thursday, October 09, 2003 4:21 PM, Larry Jones [SMTP:[EMAIL PROTECTED] wrote: Andy Jones writes: So when I went to commit the files back in my local working copy I got filename created independantly by second party. I couldn't merge away the conflict. In the end I just cvs remove'd the version from the import. My question is, was there a better, cleaner way out of that conflict? Temporarily rename your local file; do a cvs rm on the original name to unadd it; update to get the file from the repository; check to be sure that you really want your local file instead; then rename your local file back, replacing the one you just got. Shouldn't a cvs update have merged the differences between the two versions? As far as CVS knows, the two file have nothing whatsoever to do with each other. Without a common ancestor, there's nothing to merge -- you'd just have one big conflict with the entire contents of both files, so there's no point in even trying. -Larry Jones Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS patch for unedit -e
On Thu, Oct 09, 2003 at 09:42:40AM +0200, Krzysztof GORBIEL wrote: I have also tried to point my browser to the link attached in one of replies (dated 2001) but I got message: Permission: User Not Found: Only members of this project have permission to view this page (you are not listed as a member of this project You could always join... If it's the main CVS project on cvshome.org, I believe anyone's allowed to join with read-only access. Approval is only required because the software they're using to host the site won't let them turn off that feature. In other words, if you're asking for read-only access, approval is required, but isn't too hard to get. At least, that's how it was when I joined a year or two ago; is it still the case? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
locking entire tree for write
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Correct me if I am wrong, but there is no good reason for the lock_tree_for_write calls in admin.c, edit.c, and watch.c. The three files contain four calls and all are of the form: ~lock_tree_for_write ~start_recursion(...CVS_LOCK_NONE...) ~Lock_Cleanup with no intervening calls. I believe that in all four locations this could be replaced with the single call to: ~start_recursion(...CVS_LOCK_WRITE...) as cvs tag and rtag do and that this would be more efficient, allowing only a directory at a time to be locked rather than locking an entire tree for the duration of the entire operations. Just wanted to run this by the list before I changed those calls on stable. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- My name is not Dr. Death. My name is not Dr. Death. My name is not Dr. Death... ~ - Bart Simpson on chalkboard, _The Simpsons_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/hcOuLD1OTBfyMaQRAqnZAKCHoSLFL4lB/ejg18UJKyGEsKZv/QCgvjWd 7bWsJiSUdqZgWLES1cRbdNk= =vA3R -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS and NFS: Questions
Regarding an NFS mounted repository: We have a Unix server (dev30) with cvs version 1.11 loaded on it that is NFS mounted to a disk that contains our repository ( /cvs ). THIS IS THE ONLY SERVER THAT MAKES AN NFS MOUNT TO THE DISK THAT CONTAINS OUR REPOSITORY. We did this for two reasons: 1) Speed (checkout times were 3 - 4 times faster than when the repository existed on dev30 itself) 2) Safety and Recovery (if dev30 crashes, all we have to do is mount our respository to the backup machine and no time is lost) Our pserver connection in /etc/inetd.conf looks like this: cvspserver stream tcp nowait root/files0/cvsadmin/cvs-1.11/bin/cvs cvs -f --allow-root=/cvs/CVS_REPOSIT pserver We then use the pserver connection to checkin and checkout from our repository via WinCVS, Eclipse and various other GUI cvs clients. I realize there are known issues with CVS and NFS, dealing with corruption of checked in files. I have a few questions regarding this: 1) Would these issues ONLY occur in matters where there was MORE THAN ONE server mounting the repository over NFS (because then you are dealing with the potential of locked files, etc) ? 2) Asked another way, if we have just one server dedicated to cvs and it is the ONLY mount to the repository that exists, are we ok or still at risk? 3) If we are still at risk, then I assume that to avoid using NFS mounting, our repository must exist on the same server CVS is set up on? 4) If so, this will negate our ability to quickly and safely re-mount the repository to another machine in case the main server fails. Any options to this? 5) Or, is there an option to the pserver connection ( -allowroot = ) setting in inetd.conf that would allow you to connect to a remote repository? -Cant imagine anyway besides an NFS mount, but thought Id throw it out there. There is Samba mounting etc, but I would imagine that would be even worse. Thank you, -Richard __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS patch for unedit -e
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Siegerman wrote: | cvshome.org, I believe anyone's allowed to join with read-only | |access. Approval is only required because the software they're |using to host the site won't let them turn off that feature. In |other words, if you're asking for read-only access, approval is |required, but isn't too hard to get. | |At least, that's how it was when I joined a year or two ago; is |it still the case? That's still the case. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- I wouldn't bring up Paris right now. It's poor salesmanship. - Humphrey Bogart as Rick, _Casablanca_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/hdQ1LD1OTBfyMaQRAnQHAJ9YNDnrBVfJSlnjz1xbh75f/vXEjACfeWMj hnc2l3O4C26W+bjXZdPmkDA= =IL8S -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and NFS: Questions
Richard Pfeiffer writes: We have a Unix server (dev30) with cvs version 1.11 loaded on it that is NFS mounted to a disk that contains our repository ( /cvs ). THIS IS THE ONLY SERVER THAT MAKES AN NFS MOUNT TO THE DISK THAT CONTAINS OUR REPOSITORY. [...] 1)Would these issues ONLY occur in matters where there was MORE THAN ONE server mounting the repository over NFS (because then you are dealing with the potential of locked files, etc) ? No. There is a potential problem with locking across NFS, but it has never been reported as actually occurring in practice and, if it did, it would just result in a denial of service, not repository corruption. 2)Asked another way, if we have just one server dedicated to cvs and it is the ONLY mount to the repository that exists, are we ok or still at risk? Still at risk. The problem is not with multiple NFS clients, but with interoperability between different NFS client and server implementations. If you use the same NFS implementation for both the client and server system, you will almost certainly not have any problems. Similarly, if your NFS server is a system that's specifically marketed as a file server and has been tested with a wide variety of clients, you are unlikely to have any problems. You are most likely to have problems when you use a general-purpose system as a server and have very different NFS implementations on the client and server (e.g., one is a commercial Unix system and the other is a Linux system). 3)If we are still at risk, then I assume that to avoid using NFS mounting, our repository must exist on the same server CVS is set up on? Correct. 4) If so, this will negate our ability to quickly and safely re-mount the repository to another machine in case the main server fails. Any options to this? You're just trading one risk for another. Sure, if your CVS server machine dies you can mount the disk on another machine, but what are you going to do if your NFS server machine dies? Is your CVS server really that much less reliable than your NFS server? -Larry Jones Like I'm going to get any sleep NOW. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and NFS: Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Pfeiffer wrote: |Regarding an NFS mounted repository: | |1)Would these issues ONLY occur in matters where |there was MORE THAN ONE server mounting the |repository over NFS (because then you are dealing |with the potential of locked files, etc) ? Many of the issues are related to locking. CVS uses a successful mkdir(lockdir) to prevent other processes from creating locks. As I understand it, caching issues in NFS clients can cause two processes to receive success codes from the mkdir call at the same time even though one of them fails on the server end. The two processes can then happily start writing the same archive files, causing corruption. I'm uncertain whether this is an issue when only a single NFS client has mounted the NFS server. Regardless, you can work around this problem by setting the LockDir= option in CVSROOT/config to point to a locally mounted directory provided all the CVS clients are running on the same machine. The other NFS issues that frequently arise are much more troublesome. Apparently, especially with non-homogenous NFS implementations, interoperability problems can cause random NUL bytes in the communication stream to be written to the archive files. This is trouble and there is no workaround available. This is why NFS is usually discouraged for use with CVS. |3)If we are still at risk, then I assume that to |avoid using NFS mounting, our repository must |exist on the same server CVS is set up on? Yes. |4) If so, this will negate our ability to |quickly and safely re-mount the repository to |another machine in case the main server fails. |Any options to this? RAID for local data redundancy and nightly backups? YMMV. Take my advice with a grain of salt and use it at your own risk. :) Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- Man who run in front of car get tired. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/hdOELD1OTBfyMaQRApMxAJ9Aw9fHa+mmK1Rkvg49xvG7scGFMwCgmsKh sRZYSwOX2omXCh96HSZY510= =Lk9p -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: filename created independently by second party
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: | As far as CVS knows, the two file have nothing whatsoever to do with | |each other. Without a common ancestor, there's nothing to merge -- |you'd just have one big conflict with the entire contents of both files, |so there's no point in even trying. Well, there are at least three points: 1. The files are likely to have a similar base given the similar name, as has been the case nearly every time I have encountered this problem myself, and we might be able to work out something with merging... if the diff between the two files is under a certain proportional size, then the diff could probably usefully be inserted into the file between merge markers for the user. 2. Users would have less to learn since the merge markers would mean just what they meant everywhere else and this question wouldn't need to be in the FAQ and asked as often as it is. :) 3. There is a similar message generated after a join from a branch where the file was added to another where it was added separately, and this information can be lost after a simple touch. In this case, putting the merge markers in would prevent that lost information. Of course, I don't have time to write the patch myself. I'm just always hopeful that someone will be inspired by my extraordinary insights! ;) Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- I wouldn't bring up Paris right now. It's poor salesmanship. - Humphrey Bogart as Rick, _Casablanca_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/hdcrLD1OTBfyMaQRAqGTAKCJ9O6vexw75KD4D2P7c7d6ezgW6QCg8ab1 YxsavT1HJ9LLhrCXiFT4tnA= =yyGG -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and NFS: Questions
Derek Robert Price writes [about NFS-mounted repositories]: Many of the issues are related to locking. No, they're not. We've never had a report of a problem related to locking on NFS. CVS uses a successful mkdir(lockdir) to prevent other processes from creating locks. As I understand it, caching issues in NFS clients can cause two processes to receive success codes from the mkdir call at the same time even though one of them fails on the server end. The two processes can then happily start writing the same archive files, causing corruption. No. NFS guarantees that mkdir() is an atomic operation, so it can't be cached and two clients can't both get a successful return. The one theoretical problem is that mkdir() isn't idempotent (you can't do it twice and get the same result both times). If the client succesfully creates the directory but the response from the NFS server gets lost, the client will retry the mkdir() which will then fail. In this case, the client has created the lock but thinks that someone else has. This orphan lock will never be removed by CVS and thus prevents anyone from locking the directory, but it does not allow corruption. It has also never been reported in practice. I'm uncertain whether this is an issue when only a single NFS client has mounted the NFS server. Regardless, you can work around this problem by setting the LockDir= option in CVSROOT/config to point to a locally mounted directory provided all the CVS clients are running on the same machine. That's a very important proviso. I would strongly recommend against it unless you have the NFS server configured so that the filesystem can't possibly be mounted on any other machine. The other NFS issues that frequently arise are much more troublesome. Apparently, especially with non-homogenous NFS implementations, interoperability problems can cause random NUL bytes in the communication stream to be written to the archive files. This is trouble and there is no workaround available. This is why NFS is usually discouraged for use with CVS. This is the real problem. In all the cases I've seen, there are one or more blocks of NULs in the RCS files instead of the legitimate data, implying that those blocks were never written by the NFS server. Both the client and server have been used successfully with other servers and clients, so it isn't clear whether the real problem is in the client, the server, or both. As far as I know, no one has isolated the problem, but it isn't unique to CVS: at least one of my company's CAD packages has encountered exactly the same problem. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: filename created independently by second party
Derek Robert Price writes: 1. The files are likely to have a similar base given the similar name, as has been the case nearly every time I have encountered this problem myself, and we might be able to work out something with merging... if the diff between the two files is under a certain proportional size, then the diff could probably usefully be inserted into the file between merge markers for the user. So you're proposing doing a 2-way diff in that case? As far as I know, the existing diff code always does 3-way diffs, so that would probably require quite a bit of infrastructure. -Larry Jones Oh yeah? You just wait! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
limit project size
howdy, is it possible to limit the maximum project size in some way, depending on the project, eg i create a project A and set the maximum size to NumberSoMuch1 and i create a project B and set the maximum size to NumberSoMuch2 any scripts? tnx, ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: filename created independently by second party
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: |Derek Robert Price writes: | |1. The files are likely to have a similar base given the similar name, |as has been the case nearly every time I have encountered this problem |myself, and we might be able to work out something with merging... if |the diff between the two files is under a certain proportional size, |then the diff could probably usefully be inserted into the file between |merge markers for the user. | | |So you're proposing doing a 2-way diff in that case? As far as I know, |the existing diff code always does 3-way diffs, so that would probably |require quite a bit of infrastructure. I don't have time to go through the whole man page tonight, but it seems to me that diff's if-then-else format and the --*-group-format=FORMAT options, if they can't implement the result we want exactly, should require little hacking to persuade them to do so. Nevermind. Found the relevant option in diff's info page - it shouldn't require any hacking at the diff source at all: - --changed-group-format=' % === % |' Or something close to that. Since the format specifier is just a string, the revision or name of a file could be added to the string with ease to match the other merge output formats. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/hfZcLD1OTBfyMaQRAjl/AJ9QKtUxaxmBDd8LoNMOP32+l+TcbACgsMD1 SZ5tbg0aY43FytZye017MMk= =lm86 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
improper behavior or improper usage?
CVS is not behaving as expected, and causing great difficulty. We have a baseline tag DEV and wish to add to it any files with a tag READY_FOR_DEV so we issue a command cvs checkout -r DEV -r READY_FOR_DEV module but we end up with only the stuff maerked READY_FOR_DEV What we get is only the last revision mentioned. If we ask for cvs update -r READY_FOR_DEV -r DEV module then we only get DEV. If I say cvs update -j DEV -j READY_FOR_DEV module I only get READY_FOR_DEV merged with anything from DEV. None of this is right. We need the UNION of the two tags, not the intersection! = Mark Jaffe| (408) 972-9638 (home) Chief Wizard | (408) 807-1530 (cell) Computer Wizards | (425) 795-6421 (FAX) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
help on pserver connection
hello to all.. ... as of the moment i succesfully setup a winNT CVS server and its not that hard at all. workstations can login/logout checkin/checkout files but since we are switching all workstations to linux, i want to try it in linux. im having hard time seting up a CVS SERVER in a redhat9 environment. im encountering this problem: 'cvs [login aborted]: reading from server: Connection reset by peer' as i've read http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_21.html#SEC184 it says that i am missing pserver in my 'inetd.conf' but i have it right there this is my 'inetd.conf' file cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/repo pserver that is in one line running 'nmap localhost' on the server i can see '2401/tcp opencvspserver' in it.. im wondering what else could be wrong -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s: a- C U P+ L+++ E W+ N++ o- K- w--- O-- M+ V-- PS PE++ Y+ PGP- t--- 5-- X++ R tv++ b+ DI-- D+ G++ e h! r++ y-- --END GEEK CODE BLOCK-- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: help on pserver connection
On Fri 10 Oct 03, 11:43 AM, kent emia [EMAIL PROTECTED] said: hello to all.. ... as of the moment i succesfully setup a winNT CVS server and its not that hard at all. workstations can login/logout checkin/checkout files but since we are switching all workstations to linux, i want to try it in linux. im having hard time seting up a CVS SERVER in a redhat9 environment. im encountering this problem: 'cvs [login aborted]: reading from server: Connection reset by peer' as i've read http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_21.html#SEC184 it says that i am missing pserver in my 'inetd.conf' but i have it right there this is my 'inetd.conf' file cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/repo pserver that is in one line running 'nmap localhost' on the server i can see '2401/tcp opencvspserver' in it.. im wondering what else could be wrong hi kent, i'm a cvs newbie, but here are some ideas: 1. anytime you edit /etc/inetd.conf, you need to restart the inetd service by doing: /etc/init.d/inetd restart i thought redhat used xinetd, though (i'm exclusively debian). 2. try using tcpdump to make sure packets are being received: tcpdump -i eth0 tcp port 2401 3. don't forget your log files. i'm not sure where your syslogd will put the logs on redhat, so you can just grep for them: # cd /var/log # grep cvs * | less there *should* be something in there. 4. look in /etc/hosts.deny and /etc/hosts.allow. many people put ALL: ALL in /etc/hosts.deny and only allow services on a host by host (or network by network) basis. this is the most secure way to firewall: shut everything off and then turn stuff on little by little, rather than allowing everything and walling things off service by service. hth, pete -- GPG Instructions: http://www.dirac.org/linux/gpg GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: help on pserver connection
Hi!
I think the thing you have done wrong is to not visit the latest of the
CVS Cederqvist manual.
It shows that after the RedHat 7 distribution the control for cvspserver
had shifted to the xnetd services avialble as separate files under the
/etc/xinetd.d directory. Here you create a file named cvspserver and
feed in the following contents to it.
# default: on
#
# service cvspserver
#
service cvspserver
{
disable = no
id = cvspserver
env = HOME=/home/cvs
socket_type = stream
protocol= tcp
port= 2401
wait= no
user= root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/cvs pserver
}
Where server_args is the place where you give the path to your
repository.
Hope this helps. For better understanding read the Cederqvist Manual on
CVS 1.11.5, this can be found on http://www.cvshome.org/
Gagneet
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED] On Behalf
|Of kent emia
|Sent: Friday, 10 October, 2003 9:13 AM
|To: info-CVS
|Subject: help on pserver connection
|
|
|hello to all.. ... as of the moment i succesfully setup a
|winNT CVS server and its not that hard at all. workstations
|can login/logout checkin/checkout files
|
|but since we are switching all workstations to linux, i want
|to try it in linux. im having hard time seting up a CVS SERVER
|in a redhat9 environment.
|
|im encountering this problem:
|'cvs [login aborted]: reading from server: Connection reset by peer'
|
|as i've read
|http://www.cvshome.org/docs/manual/cvs-|1.11.7/cvs_21.html#SEC18
|4 it says that i am missing pserver in my 'inetd.conf' but i
|have it right there this is my 'inetd.conf' file
|
|cvspserver stream tcp nowait root /usr/local/bin/cvs cvs
|--allow-root=/repo pserver
|
|that is in one line
|
|running 'nmap localhost' on the server i can see
|'2401/tcp opencvspserver' in it..
|
|im wondering what else could be wrong
|
|
|--
|-BEGIN GEEK CODE BLOCK-
|Version: 3.1
|GCS d- s: a- C U P+ L+++ E W+ N++ o- K- w---
|O-- M+ V-- PS PE++ Y+ PGP- t--- 5-- X++ R tv++ b+ DI-- D+
|G++ e h! r++ y--
|--END GEEK CODE BLOCK--
|
|
|
|___
|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: [cvsgui] Duplicating CVS repository from one server to another?
Title: Message Hi! You just need to copy the files with the existing permissions to the new server. Also, there is a GUI available with WinCVS, if that is what you are using which allows the client to change the 'root' on the local machines. (this is helpful if you have changed the name of the server as well). The Macro is available under the Macros Menu - TCL - Change CVSRoot (GUI). The copying will be for all the users, groups and repositories you created with all the existing permissions intact. I think there should exist a script to do this work also, but for that you will have to wait for the others to answer this query.. Gagneet -Original Message-From: Barry [mailto:[EMAIL PROTECTED] Sent: Friday, 10 October, 2003 1:58 AMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: [cvsgui] Duplicating CVS repository from one server to another?All,If I have CVS setup in server A. How can I duplicate that in a new server B?In another word, how can I copy all the CVS contents (scripts, setups,modules...etc) from A to B?ThanksBarry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: [cvsgui] Any gui tools to show the branch structures?
Title: Message Hi! Well I think this is the most common question being asked by all and Oliver has answered it many a times. No as yet there is no such tool (although Oliver has made many attempts to create one.. ). The best you can do is go to the most used file (the one used by all or the one with most commits) and see the graph for this. Oliver should be able to guide you better on this. Gagneet -Original Message-From: Barry [mailto:[EMAIL PROTECTED] Sent: Friday, 10 October, 2003 1:58 AMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: [cvsgui] Any gui tools to show the branch structures?Hi all,Is there any tools to show the whole cvs repository structure? Versions andbanches of files? Producing reports and all?ThanksBarry Yahoo! Groups Sponsor ADVERTISEMENT To unsubscribe from this group, send an email to:[EMAIL PROTECTED]Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: improper behavior or improper usage?
Mark Jaffe writes [in exceedingly long lines]: CVS is not behaving as expected, and causing great difficulty. Your expectations are wrong. The CVS philosophy is that you tag entire modules, not bits and pieces. -Larry Jones It's no fun to play games with a poor sport. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: help on pserver connection
On Fri, 2003-10-10 at 12:02, [EMAIL PROTECTED] wrote: On Fri 10 Oct 03, 11:43 AM, kent emia [EMAIL PROTECTED] said: hello to all.. ... as of the moment i succesfully setup a winNT CVS server and its not that hard at all. workstations can login/logout checkin/checkout files but since we are switching all workstations to linux, i want to try it in linux. im having hard time seting up a CVS SERVER in a redhat9 environment. im encountering this problem: 'cvs [login aborted]: reading from server: Connection reset by peer' as i've read http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_21.html#SEC184 it says that i am missing pserver in my 'inetd.conf' but i have it right there this is my 'inetd.conf' file cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/repo pserver that is in one line running 'nmap localhost' on the server i can see '2401/tcp opencvspserver' in it.. im wondering what else could be wrong hi kent, i'm a cvs newbie, but here are some ideas: 1. anytime you edit /etc/inetd.conf, you need to restart the inetd service by doing: /etc/init.d/inetd restart im did restart it... i thought redhat used xinetd, though (i'm exclusively debian). ok 2. try using tcpdump to make sure packets are being received: tcpdump -i eth0 tcp port 2401 here's the output [EMAIL PROTECTED] admin]# tcpdump -i eth0 tcp port 2401 tcpdump: listening on eth0 13:06:52.120827 leprechaun.cdr.com.55072 genesis.cdr.com.cvspserver: S 1493157523:1493157523(0) win 5840 mss 1460,sackOK,timestamp 10302474 0,nop,wscale 0 (DF) 13:06:52.120899 genesis.cdr.com.cvspserver leprechaun.cdr.com.55072: S 1166485185:1166485185(0) ack 1493157524 win 5792 mss 1460,sackOK,timestamp 8746928 10302474,nop,wscale 0 (DF) 13:06:52.121104 leprechaun.cdr.com.55072 genesis.cdr.com.cvspserver: . ack 1 win 5840 nop,nop,timestamp 10302474 8746928 (DF) 13:06:52.121482 leprechaun.cdr.com.55072 genesis.cdr.com.cvspserver: P 1:71(70) ack 1 win 5840 nop,nop,timestamp 10302474 8746928 (DF) 13:06:52.121518 genesis.cdr.com.cvspserver leprechaun.cdr.com.55072: . ack 71 win 5792 nop,nop,timestamp 8746928 10302474 (DF) 13:06:52.123421 genesis.cdr.com.cvspserver leprechaun.cdr.com.55072: R 1:1(0) ack 71 win 5792 nop,nop,timestamp 8746928 10302474 (DF) from the client [EMAIL PROTECTED] kent]$ cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/repo CVS password: cvs [login aborted]: reading from server: Connection reset by peer [EMAIL PROTECTED] kent]$ 3. don't forget your log files. i'm not sure where your syslogd will put the logs on redhat, so you can just grep for them: # cd /var/log # grep cvs * | there's no cvs there *should* be something in there. im wondering why there's no log... 4. look in /etc/hosts.deny and /etc/hosts.allow. many people put ALL: ALL in /etc/hosts.deny and only allow services on a host by host (or network by network) basis. this is the most secure way to firewall: shut everything off and then turn stuff on little by little, rather than allowing everything and walling things off service by service. my hosts.deny is empty and so is host.allow hth, pete -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s: a- C U P+ L+++ E W+ N++ o- K- w--- O-- M+ V-- PS PE++ Y+ PGP- t--- 5-- X++ R tv++ b+ DI-- D+ G++ e h! r++ y-- --END GEEK CODE BLOCK-- -- Kent C. Emia -- Software Studio for Concepts, Development and Research, Corp. : Unit 307 3rd flr Central Plaza 1, J.P. Laurel Avenue, Davao City 8000 Philippines : http://www.cdr.com.ph : +(6382)225-3728 - my IM's - icq : 347511398 yahoo : kent_emia hotmail : kentskie - my page : http://www.cdr.com.ph/~kent/ - my mobile - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
