Date: Tue, 28 Mar 2000 12:41:37 -0800 (PST) From: Doug Barton <Doug@gorean.org> To: Kris Kennaway <kris@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Peter Wemm <peter@netplex.com.au> Subject: Re: cvs repository nits and gnats Message-ID: <Pine.BSF.4.21.0003281215260.38091-100000@dt051n0b.san.rr.com> In-Reply-To: <Pine.BSF.4.21.0003281052550.46676-100000@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the response...
On Tue, 28 Mar 2000, Kris Kennaway wrote:
> On Tue, 28 Mar 2000, Doug Barton wrote:
>
> > src/TODO-2.1, src/usr.sbin/xntpd, etc. There were a large number in
> > contrib, probably detritus from imports, etc. I'm not sure if this is
> > significant, it obviously doesn't do any harm. I just thought I'd
> > mention it.
>
> CVS has no concept of removing a directory
Hrrmm... cool! I've always used the -P option, so I've not seen
this before. Having always been a "customer" of cvs rather than an
administrator I'm learning new things at a rapid pace.
> > Slightly more serious was the presence of various lock
> > files/directories. Specifically, one in src/games/primes killed my co as
> > an unpriviliged user because it was set 700 and owned by root. The co
> > failed because it couldn't create a lock file. I did a 'find . -name
> > \*\#\* in my CVSROOT and found several other files like this. Deleting
> > them did no harm, and they didn't return when I ran cvsup again.
>
> I havent seen this.
My gut feeling is that it's a timing issue. I happened to have
been cvsup'ing when someone actually had a lock on something in the
repository. Still I think it's odd that A) the cvsup "mirrors" of the
master repository picked up these files, B) that my cvsup of the
repository picked them up, and C) having picked them up, it didn't delete
them when they were deleted from the real respository. FWIW, I always use
cvsup7, and I found these lock files in both my home and work copies.
> I ran into this the other day and was advised to mount the CVS repository
> via NFS instead of accessing it via rsh. This indeed solves the problem.
Yes, that's what I do everywhere _else_, but this particular
machine's network position within our firewall makes that impossible at
this time. We've outgrown a class C for our internal machines so we're
blending a new one in and haven't gotten all the filtering in place
yet. rsh was one "hole" that was available to me, and with proper wrapping
it's pretty safe on our internal network.
Thanks,
Doug
--
"So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
The master simply replied, "Mu."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0003281215260.38091-100000>