Re: cvs repository nits and gnats
John Polstra wrote: [My silly speculation about cvs lockfiles and cvsup deleted] > I think you may be misinterpreting the symptoms, That's entirely possible. > because I don't know > of any way for lock files to propagate off of freefall with CVSup. > All lock files are specifically excluded in the server's config files > -- they won't even make it to cvsup-master, let alone to the mirrors > such as cvsupN.freebsd.org. What were the names of the files you > thought were lock files? It sounds to me like maybe they were created > by something on your local system -- not mirrored via CVSup. Well, I don't make any commits to this cvs tree, only checkouts. Unfortunately I didn't save the filename of any of the really incriminating files. The one that killed my checkout was a directory in src/games/primes. I also found these files in the logs I did keep, from the /usr/src that was checked out with cvsup, not cvs: -rw-r- 1 root wheel7.0k Mar 22 09:55 .#Makefile.1.232 -rw-r- 1 root wheel 23k Mar 8 22:28 .#Makefile.inc1.1.120 -rw-r- 1 root wheel 24k Mar 24 12:21 .#UPDATING.1.58 I also found this file in my CVSROOT on one of my repositories: ./sup/src-all/#cvs.cvsup-749.0 It's actually dated March 24 1998, which predates the creation of this repository. Hrrrmm Aha! Part of the mystery solved at least. I started this repository from the snapshot CD dated 7/5/99. I just untarred that repository snapshot into a new directory and found the above file, and the lock directory I mentioned earlier: drwxr-x--- 2 doug wheel 512 Jul 30 1999 ./src/games/primes/#cvs.rfl.scratch1.cdrom.com.381 -rw-r- 1 doug wheel2.0M Mar 24 1998 ./sup/src-all/#cvs.cvsup-749.0 In any case, my purpose for posting was to notify the PTB in case there was a problem. If anyone is qualified to state categorically that there is no problem it's probably you. :) The actual lock directory above was my chief concern, and now that I know I didn't inherit it from cvsup, I'm happy. Thanks for taking the time to help me learn... 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs repository nits and gnats
In article <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]> wrote: > > > 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 think you may be misinterpreting the symptoms, because I don't know of any way for lock files to propagate off of freefall with CVSup. All lock files are specifically excluded in the server's config files -- they won't even make it to cvsup-master, let alone to the mirrors such as cvsupN.freebsd.org. What were the names of the files you thought were lock files? It sounds to me like maybe they were created by something on your local system -- not mirrored via CVSup. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs repository nits and gnats
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs repository nits and gnats
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 (possibly excepting repository surgery), so unless you pass the -P option (prune empty directories) you get stuck with all of the old ones. > 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. > Finally, a question. I'm doing my cvs co/update on this machine > remotely via rsh (within our secure network of course). When I start the > update it creates an entire src directory tree in /tmp. This takes a > great deal of time, so I'm wondering if this can be avoided somehow? I'm > doing the cvs rsh as root on the client machine, and as an unpriviliged > user on the cvs server machine. 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. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs repository nits and gnats
Greetings, I'm working on a new project and had the need for a clean set of sources on a new machine. In the course of setting it all up I neglected to copy over my .cvsrc file which has (amongst other things) 'co -P'. In checking out the sources for RELENG_4 I ended up with a large number of empty directories. Some of them were obviously relics of the past, like 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. 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. Finally, a question. I'm doing my cvs co/update on this machine remotely via rsh (within our secure network of course). When I start the update it creates an entire src directory tree in /tmp. This takes a great deal of time, so I'm wondering if this can be avoided somehow? I'm doing the cvs rsh as root on the client machine, and as an unpriviliged user on the cvs server machine. Hope this is helpful, 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
