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... Philip Guenther
