On Wed, 2005-10-12 at 18:08 -0700, Mike Stump wrote: > On Oct 11, 2005, at 7:42 PM, Daniel Berlin wrote: > > So, Mike Stump said his update times with svn from toolchain.org > > were a > > little slow. > > > Let me know if it's still slow for you. > > Ok, had a chance to upgrade my svn to 1.2.3, and time from gcc.gnu.org: > > $ cd gcc > $ time svn update *.c > [ lots o output that is annoying ] > real 3m28.134s > user 0m7.665s > sys 0m5.403s
> From top: > Networks: 16981 ipkts/2674K 10405 opkts /1370K > Disks: 106 reads/781K 345 writes/4755K vs > mrs $ time svn update > real 0m4.833s > user 0m0.577s > sys 0m0.778s > From top: > Networks: 176 ipkts/20K 35 opkts /7K > Disks: 6 reads/48K 864 writes/12894K > > All operations were hot nops. This is actually expected behavior right now. svn up *.c ends up being the equivalent of for x in *.c; svn update $x; done It treats each argument as a separate update operation, with all the protocol overhead that incurs. It would be nice to change that, but it's actually an uncommon enough use case that it hasn't been a priority. svn up just says "I have revision x of directory, give me the latest", and applies those change.s svn up *.c reports the revision for each file, and asks for the update, for each file, as a seperate update. The current remote access API has no way of saying "Give me the updates for only these files", only "give me the update for this tree", or "give me the update for this one item". Once we come up with an API to do this, we'd probably do something like "try to find common parent of all requested updates if possible, get all revisions for those parents, only apply to selected targets". This still won't be faster than svn up with no args though, because you either end up with multiple parents you ask about (in case the updates you request are disjoint in paths), asking about the root of the repo, or you have to filter the revisions. However, remember that reghunts can now be done by global revision number, instead of just by file revisions. --Dan
