I (Julian Foad) wrote: > "Teach some WC and client 'add' functions to take the properties as > a parameter so that the whole addition including any properties can > be done all at once. ..."
I finished this and committed it in <http://svn.apache.org/r1424739>. I did this because of the update-move work: that needs more "regular" APIs to both read and write nodes in the DB. As in we should be able to read "a node" including (a reference to) its text and its props in one call. And similarly write "a node" in one call. Afterwards, I ran a test to see whether this makes a noticeable speed difference to "svn add", just as a curiosity -- I don't really care about that and that wasn't any part of my goal. Speed freaks may be interested in the outcome. In an unrealistic manual test, I put an unversioned export of the svn trunk inside an otherwise empty WC, and ran "svn add" with 25 auto-props defined on every file. $ time svn add wc/tree/ --config-option='config:miscellany:enable-auto-props=1' --config-option='config:auto-props:*=a=a;b=b;c=c;d=d;e=e;f=f;g=g;h=h;i=i;j=j;k=k;l=l;m=m;n=n;o=o;p=p;q=q;r=r;s=s;t=t;u=u;v=v;w=w;x=x;y=y' pre-patch post-patch real 0m7.00s 0m1.13s user 0m5.65s 0m0.72s sys 0m0.97s 0m0.32s This is expected because the patch eliminates the add-one-property-at-a-time-to-the-db loop. Without any auto-props: $ time svn add -q wc/tree/ pre-patch post-patch real 0m1.16s 0m0.92s user 0m0.78s 0m0.62s sys 0m0.35s 0m0.29s This was on my Ubuntu 10.10 system, ext3 FS on a spinning disk. Timings approx +/- 15%, averaged by eye from 3 runs. - Julian
