On Wed, 30 Jul 2003 [EMAIL PROTECTED] wrote: > Send Info-cvs mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.gnu.org/mailman/listinfo/info-cvs > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Info-cvs digest..." > > > Today's Topics: > > 1. Re: setting up cvs and cvsweb.... (Robert Helmer) > 2. Not waiting on #cvs.lock (gilmurra) > 3. Re: Script for a CVS only shell available? (Wu Yongwei) > 4. Re: Feature Request: admin files for "cvs import" and "cvs > add<dir>" (Wu Yongwei) > 5. Re: Puzzled with sanity.sh (Wu Yongwei) > 6. Re: Feature Request: admin files for "cvs import" and "cvs > add<dir>" (Greg A. Woods) > 7. Re: RSE's cvs import patch against the current CVS source > (Julien Wajsberg) > 8. Re: RSE's cvs import patch against the current CVS source > (Mark D. Baushke) > 9. Re: RSE's cvs import patch against the current CVS source > (Julien Wajsberg) > 10. RE: Strange diff behavior on branch (Lemke, Michael IZ/HZA-IC1) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 29 Jul 2003 11:35:00 -0700 > From: Robert Helmer <[EMAIL PROTECTED]> > Subject: Re: setting up cvs and cvsweb.... > To: bruce <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jul 29, 2003 at 12:37:58AM -0700, bruce wrote: > > I think I have CVS working... but I'm not really sure!!! > > Have you tested it? Do this on the command line : > > CVS_RSH=ssh > CVSROOT=:ext:[EMAIL PROTECTED]:/CVS > export CVS_RSH CVSROOT > cvs co <module> > > (where <module> is a name of a module you have in CVS). > > > > > I have CVSROOT set to --> :ext:[EMAIL PROTECTED]:/CVS > > Are you trying to use this CVSROOT in CVSWeb? Because CVSWeb cannot > use a remote repository, it muts be ON lserver2.mesa.com, and use > a CVSROOT like "CVSROOT=/CVS". > > > When I try to access CVSWEB from the web server, I'm getting an error > > indicating an error: > > Check the Apache error.log file. What is the error there? > > > within my /etc/profile, i have tried... > > CVSROOT="/CVS" > > This is the only one that will work. > > > within /etc/xinetd.d/cvspserver.. i have > > service cvspserver > > This does not matter for CVSWeb. > > > My questions.... I understand that you really want SSH for the security... > > But if I use CVSROOT="ext....", do I need to change the cvspserver > > information, specifically the line that has pserver..??? > > ext and pserver are mutually exclusive. > > > Assuming I get this to work..what changes need to be made regarding CVSWEB. > > I try to get CVSWEB running and I get a log error saying that the cvsweb.cgi > > script is having an issue over an invalid character... I assume that I don't > > have CVS actually running correctly.... > > No, that's a problem with the CGI. > You might want to try ViewCVS, it's easier to get running: > http://viewcvs.sourceforge.net/ > > > > I'd like to basically insure that CVS is running.. and then get CVSWEB > > running... and then be able to access CVS via a remote server as well as a > > remote browser running CVSWEB.... > > > pserver doesn't have to be running to use CVS via SSH or locally (like > CVSWeb uses). If you don't need pserver, don't run it. SSH is better. > > > > HTH, > Rob Helmer > > > > ------------------------------ > > Message: 2 > Date: Tue, 29 Jul 2003 11:55:10 -0700 > From: gilmurra <[EMAIL PROTECTED]> > Subject: Not waiting on #cvs.lock > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > I'm doing a "cvs update -P -d ..." every two hours from a cron job. > Everything works fine 'til somehow a #cvs.lock doesn't get deleted. > Every two hours another update job starts and eventually we run out of > job space. I realize some locks are valid and I'm writing a script to > inform me when a lock is more than one day old but that won't solve my > immediate problem. > > Is there a way to abort instead of waiting when a lock is set when doing > an update? > > Thanks, Frank > > > > ------------------------------ > > Message: 3 > Date: Wed, 30 Jul 2003 09:32:32 +0800 > From: "Wu Yongwei" <[EMAIL PROTECTED]> > Subject: Re: Script for a CVS only shell available? > To: <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Thank you very much. The first script is *so* goddamnedly nice and slim. I > nearly thought myself an idiot at seeing it. > > Best regards, > > Wu Yongwei > > --- Original Message from Mark Priest --- > > Wu, > > Here is a thread from the cygwin mailing list that has such a script: > <http://cygwin.com/ml/cygwin/2003-04/msg00317.html> > > Also, the scponly script at this URL http://www.sublimation.org/scponly/ has > another example. > > -Mark > > > > > ------------------------------ > > Message: 4 > Date: Wed, 30 Jul 2003 09:39:35 +0800 > From: "Wu Yongwei" <[EMAIL PROTECTED]> > Subject: Re: Feature Request: admin files for "cvs import" and "cvs > add<dir>" > To: <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Greg A. Woods wrote: > > If you're worried about that kind of threat then you have far bigger > > problems than you think. > > > > CVS is not a security tool. > > No, it is not. Yet. But I love CVS and love to have a secure CVS. (BTW, > my employer is a network security vendor :-).) > > Don't you like CVS to be more secure? > > Best regards, > > Wu Yongwei > > > > > ------------------------------ > > Message: 5 > Date: Wed, 30 Jul 2003 09:53:02 +0800 > From: "Wu Yongwei" <[EMAIL PROTECTED]> > Subject: Re: Puzzled with sanity.sh > To: <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > I knew I was having some extreme bad luck. I had already checked the > check.log file and had not found any problems. To keep myself sane, I am > sending the check.log to the list in this message. (I suppose the sanity > check is completely OK on your box?) > > Or is my Red Hat 7.3 box going insane? > > Best regards, > > Wu Yongwei > > --- Original Message from Mark D. Baushke --- > > The immediate cause of the failure will be found by looking in the > "/home/adah/src/ccvs/src/check.log" file. > > The version-1 test just runs the command: > > `pwd`/cvs --version > > and tries to compare the output with what it expects. This is a good > sanity test for the expr command in your path among other things... > > Good luck, > -- Mark > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: check.log > Type: application/octet-stream > Size: 779 bytes > Desc: not available > Url : http://mail.gnu.org/pipermail/info-cvs/attachments/20030730/5e3fb8df/check.obj > > ------------------------------ > > Message: 6 > Date: Wed, 30 Jul 2003 01:57:38 -0400 (EDT) > From: "Greg A. Woods" <[EMAIL PROTECTED]> > Subject: Re: Feature Request: admin files for "cvs import" and "cvs > add<dir>" > To: "Wu Yongwei" <[EMAIL PROTECTED]> > Cc: CVS-II Discussion Mailing List <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > [ On Wednesday, July 30, 2003 at 09:39:35 (+0800), Wu Yongwei wrote: ] > > Subject: Re: Feature Request: admin files for "cvs import" and "cvs add<dir>" > > > > Don't you like CVS to be more secure? > > No, actually I don't, at least not in the way you're suggesting. > > I want CVS to be a good source-code change tracking tool, and nothing > more. > > -- > Greg A. Woods > > +1 416 218-0098 VE3TCP RoboHack <[EMAIL PROTECTED]> > Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> > > > > ------------------------------ > > Message: 7 > Date: Wed, 30 Jul 2003 12:07:38 +0200 > From: "Julien Wajsberg" <[EMAIL PROTECTED]> > Subject: Re: RSE's cvs import patch against the current CVS source > To: [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > I just saw that 'verifymsg' is processed before 'importinfo' with your > patch. > I don't think it is the correct behaviour :) > > How about modifying this ? > Somewhere before the call to do_verify ? > > -- > Julien Wajsberg > > ---------- > Answer to Ralf S. Engelschall <[EMAIL PROTECTED]> : > ---------- > > > On Tue, Jul 29, 2003, Mark D. Baushke wrote: > > > > Any possibility to make it a feature of the mainstream CVS? > > [...] > > Also, the patch should not be conditional on the macros RSE_PATCHES or > > RSE_PATCH_IMPORTINFO, so those parts of the patch need to be removed. > > [...] > > Sure, the #ifdef/#endif wrappers are there just for two reason: to allow > me to exactly identify what code changes belong to which parts of my > larger patch set and to allow me to selectively activate/deactivate > some parts of it. For a possible inclusion into the mainstream CVS > source these would be gone, of course. As already mentioned to Mark > in a private mail, I'll try to find some time over the next weeks and > work-off my patch set by adding sanity.sh and documentation changes and > moving it up to the latest CVS HEAD version. I also will separate the > large patch set into individual smaller ones (for easier review by the > CVS developer team). > Ralf S. Engelschall > [EMAIL PROTECTED] > www.engelschall.com > > > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > > > > > > > > ------------------------------ > > Message: 8 > Date: Wed, 30 Jul 2003 03:59:41 -0700 > From: "Mark D. Baushke" <[EMAIL PROTECTED]> > Subject: Re: RSE's cvs import patch against the current CVS source > To: "Julien Wajsberg" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > Julien Wajsberg <[EMAIL PROTECTED]> writes: > > > I just saw that 'verifymsg' is processed before 'importinfo' with your > > patch. I don't think it is the correct behaviour :) > > I suggest that you should not depend on the ordering of the verifymsg as > compared to the importinfo or commitinfo. > > In client/server mode, verifymsg is processed first. In local mode, > verifymsg is usually called after the commitinfo has been called. > > It is just as reasonable to reject a commit due to a bad log message as > it is to reject it because a file is being committed does not pass some > commitinfo check. > > > How about modifying this ? > > I believe it would be a waste of time. There is still an 'enhancement' > request http://ccvs.cvshome.org/issues/show_bug.cgi?id=27 to have the > verifymsg processed only once rather than for each directory... > > > Somewhere before the call to do_verify ? > > I'd suggest that this is not a useful distraction for RSE right now. > > Thanks, > -- Mark > > > > ------------------------------ > > Message: 9 > Date: Wed, 30 Jul 2003 13:28:08 +0200 > From: "Julien Wajsberg" <[EMAIL PROTECTED]> > Subject: Re: RSE's cvs import patch against the current CVS source > To: [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > Mark D. Baushke wrote: > > > > Julien Wajsberg <[EMAIL PROTECTED]> writes: > > > > > I just saw that 'verifymsg' is processed before 'importinfo' with your > > > patch. I don't think it is the correct behaviour :) > > > > I suggest that you should not depend on the ordering of the verifymsg as > > compared to the importinfo or commitinfo. > > I don't depend of the order. It just happens in our setup that verifymsg > takes longer than other hooks. > > > In client/server mode, verifymsg is processed first. In local mode, > > verifymsg is usually called after the commitinfo has been called. > > My understanding was that commitinfo/taginfo always occurs before > verifymsg. It seems I was wrong... > > > It is just as reasonable to reject a commit due to a bad log message as > > it is to reject it because a file is being committed does not pass some > > commitinfo check. > > Yes I agree with that. > > > > How about modifying this ? > > > > I believe it would be a waste of time. There is still an 'enhancement' > > request http://ccvs.cvshome.org/issues/show_bug.cgi?id=27 to have the > > verifymsg processed only once rather than for each directory... > > > > Somewhere before the call to do_verify ? > > > > I'd suggest that this is not a useful distraction for RSE right now. > > If there is no advantage at doing that, surely it is a waste of time. > But if it adds coherence, why don't you want to add this feature in the > good way at the first time ? > > Moreover, it could help (later) if you want to modify the code in order not > to show an editor if > commitinfo is failing, for example (just a thought). > > -- > Julien > PS: sorry Mark, I hit the wrong reply button at first... > > > > > ------------------------------ > > Message: 10 > Date: Wed, 30 Jul 2003 14:51:02 +0200 > From: "Lemke, Michael IZ/HZA-IC1" <[EMAIL PROTECTED]> > Subject: RE: Strange diff behavior on branch > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain > > Not having seen a single reply I try again and ask: > > > I have a file that was initially added on a branch. If I > > do a diff based on a date I get this: > > > > $ cvs diff -D 16-jul-2003 koucopy.sh > > cvs diff: koucopy.sh is a new entry, no comparison available > > $ cvs stat koucopy.sh > > =================================================================== > > File: koucopy.sh Status: Up-to-date > > > > Working revision: 1.1.2.12 Mon Jul 21 05:48:12 2003 > > Repository revision: 1.1.2.12 > > /mnt/bflow/cvs/repos/inacom/Attic/koucopy.sh,v > > Sticky Tag: B_PROD (branch: 1.1.2) > > Sticky Date: (none) > > Sticky Options: (none) > > $ cvs log koucopy.sh > > > > RCS file: /mnt/bflow/cvs/repos/inacom/Attic/koucopy.sh,v > > Working file: koucopy.sh > > head: 1.1 > > branch: > > locks: strict > > access list: > > symbolic names: > > B_PROD: 1.1.0.2 > > keyword substitution: kv > > total revisions: 13; selected revisions: 13 > > description: > > ---------------------------- > > revision 1.1 > > date: 2002/12/13 14:08:29; author: bflowadm; state: dead; > > branches: 1.1.2; > > file koucopy.sh was initially added on branch B_PROD. > > ---------------------------- > > revision 1.1.2.12 > > date: 2003/07/21 05:48:12; author: bflowadm; state: Exp; > > lines: +5 -2 > > ... > > $ cvs -v > > > > Concurrent Versions System (CVS) 1.12.1 (client/server) > > > > > > > > Is this expected behavior? Diffs on revisions (-r 1.1.2.10) work. > > > > Thanks, > > Michael
Hi M, Try to update everythin' first, co module and you should get the retrieving revisions if the diffs work. Cheers, B > > > > ------------------------------ > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > > > End of Info-cvs Digest, Vol 8, Issue 31 > *************************************** > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs