It was mainly a disk space problem: when updating from zev.ez.no, the update script needs temporarily around 2.6 GB for sanity checking and correction ... websvn had generated a cache by the action of search robots and left a few hundred MB on the volume holding pubsvn. That means a complete directory with all ezp files for every revision + tar balls for all directories. Hence the 60GB :-) Furtunately, bandwidth is not a problem here.
No, it was there a long time, but the rule for websvn was missing
I first thought is was a good idea to let the spiders fill the cache, now I don't think that anymore :-) cya
