[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Info-cvs Digest, Vol 8, Issue 31
From: |
Bogdan Serbanoiu |
Subject: |
Re: Info-cvs Digest, Vol 8, Issue 31 |
Date: |
Wed, 30 Jul 2003 17:00:26 +0200 (CEST) |
On Wed, 30 Jul 2003 address@hidden wrote:
> Send Info-cvs mailing list submissions to
> address@hidden
>
> 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
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> 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 <address@hidden>
> Subject: Re: setting up cvs and cvsweb....
> To: bruce <address@hidden>
> Cc: address@hidden, address@hidden
> Message-ID: <address@hidden>
> 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:address@hidden:/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:address@hidden:/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 <address@hidden>
> Subject: Not waiting on #cvs.lock
> To: address@hidden
> Message-ID: <address@hidden>
> 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" <address@hidden>
> Subject: Re: Script for a CVS only shell available?
> To: <address@hidden>
> Message-ID: <address@hidden>
> 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" <address@hidden>
> Subject: Re: Feature Request: admin files for "cvs import" and "cvs
> add<dir>"
> To: <address@hidden>
> Message-ID: <address@hidden>
> 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" <address@hidden>
> Subject: Re: Puzzled with sanity.sh
> To: <address@hidden>
> Message-ID: <address@hidden>
> 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" <address@hidden>
> Subject: Re: Feature Request: admin files for "cvs import" and "cvs
> add<dir>"
> To: "Wu Yongwei" <address@hidden>
> Cc: CVS-II Discussion Mailing List <address@hidden>
> Message-ID: <address@hidden>
> 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 <address@hidden>
> Planix, Inc. <address@hidden> Secrets of the Weird <address@hidden>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 30 Jul 2003 12:07:38 +0200
> From: "Julien Wajsberg" <address@hidden>
> Subject: Re: RSE's cvs import patch against the current CVS source
> To: address@hidden
> Message-ID:
> <address@hidden>
> 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 <address@hidden> :
> ----------
>
>
> 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
> address@hidden
> www.engelschall.com
>
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 30 Jul 2003 03:59:41 -0700
> From: "Mark D. Baushke" <address@hidden>
> Subject: Re: RSE's cvs import patch against the current CVS source
> To: "Julien Wajsberg" <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
>
> Julien Wajsberg <address@hidden> 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" <address@hidden>
> Subject: Re: RSE's cvs import patch against the current CVS source
> To: address@hidden
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> Mark D. Baushke wrote:
>
>
> > Julien Wajsberg <address@hidden> 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" <address@hidden>
> Subject: RE: Strange diff behavior on branch
> To: "'address@hidden'" <address@hidden>
> Message-ID:
> <address@hidden>
> 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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
>
> End of Info-cvs Digest, Vol 8, Issue 31
> ***************************************
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Info-cvs Digest, Vol 8, Issue 31,
Bogdan Serbanoiu <=