On Fri, 27 Jan 2012, Philip Guenther wrote: >On Fri, Jan 27, 2012 at 12:10 PM, Dave Anderson <d...@daveanderson.com> >wrote: >> I've run into this problem perhaps a dozen times over the past several >> months while running amd64-current, most recently at 15:53 2012/1/26 EST >> while running a system built from source updated at about 14:30 >> 2012/1/21 EST: when trying to update the xenocara source tree there is a >> very long (perhaps infinite) delay between issuing the 'cvs ...' command >> and the start of any visible activity. In this most recent case the >> delay was about 9 hours. Updating the src and ports source trees at >> about the same time and using the same CVSROOT has always worked OK; >> there's some delay but not a really long one. And sometimes the >> xenocara update has worked without any problem. When it doesn't, 'rm >> -rf /usr/xenocara' followed by reloading from the 5.0-release CD has >> always allowed a subsequent cvs update to work. >> >> The command I'm using is >> # cd /usr/xenocara && cvs -d$CVSROOT -q up -Pd >> (except for the working directory, exactly the same as the command for >> updating the src or ports tree). > >I bet it'll be faster if you don't use the -P or -d options. > >The -d option to "cvs up" requires the cvs server to walk directories >that are present on the server but not present on the client. That >includes directories which are now empty because all their files have >been removed (ala "cvs rm")...of which there are a bunch in the >xenocara tree. > >The -P option requires extra work too, though it's not as bad as the >-d option, IIRC. > >Personally, I use the rule of thumb of only using -d and -P when I >have reason to believe directories have been added or removed, either >from seeing the commit email or from a build failing because a >directory is missing...
Thanks for the info. I've been using -Pd because <http://www.openbsd.org/anoncvs.html> says to use them; I haven't yet had a chance to look into how cvs works beyond reading the man page, faq, etc. Dave -- Dave Anderson <d...@daveanderson.com>
