At least on my mac, it seems to be paging in all the inodes that takes the time:
[EMAIL PROTECTED] legals 23:12:03]$ time svn status > /dev/null real 1m11.149s user 0m3.947s sys 0m10.710s [EMAIL PROTECTED] legals 23:13:38]$ time svn status -q > /dev/null real 0m5.224s user 0m1.914s sys 0m1.283s [EMAIL PROTECTED] legals 23:13:56]$ time svn status > /dev/null real 0m11.778s user 0m2.456s sys 0m2.862s [EMAIL PROTECTED] legals 23:14:16]$ time svn status -q > /dev/null real 0m4.252s user 0m1.883s sys 0m1.245s [EMAIL PROTECTED] legals 23:14:33]$ time svn status > /dev/null real 0m3.994s user 0m1.857s sys 0m1.033s On 2006-07-10, at 19:08 EDT, Benjamin Shine wrote: > Yipes! > > svn status with no args does not contact the network at all. > The empty-change-description task does "svn status -q" which *does* > contact the network. > Henry, try changing this line > svn status -q >> $TMPFILE > to just > svn status >> $TMPFILE > > and see if that gives you a speedup. If it does, I can just grep > out the ? and ! entries, which are hidden with the -q (quiet) > argument. > > On Jul 10, 2006, at 1:04 PM, P T Withington wrote: > >> On 2006-07-10, at 14:37 EDT, Henry Minsky wrote: >> >>> The empty-change-description script where svn attempts to figure >>> out what >>> has changed, when run from the top level in an entire branch >>> becomes >>> unusably slow, at least under cygwin (> 20 minutes and counting >>> on my >>> thinkpad). >>> Is there any way to speed this up? The workaround is to manually >>> remember in >>> roughly what subdirectories things are modified to cut down the >>> search space, which isn't so bad, but >>> it is nice sometimes to ask for a list of all modifications. >> >> I have the same problem and I don't know a solution. AFAICT, it is >> because svn doesn't maintain any central state on your machine so >> must search the entire subtree to see if you've changed anything. I >> haven't found a solution. It is partly why I made the svn tools be >> driven off the change message, so at least you only have to search >> the subtree once to compose the change message. After that, the file >> list is taken from the change message. >> >> _______________________________________________ >> Laszlo-dev mailing list >> [email protected] >> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
