Re: svn commit: rev 7695 - in trunk: doc/book subversion/include subversion/libsvn_fs subversion/libsvn_repos subversion/svnadmin subversion/tests/libsvn_fs

Philip Martin <philip@codematters.co.uk> writes:

> > Greg Stein said the stuff that start with '> >':
> > Is there an "optimum" direction for the deltification? If so, then I'd
> > recommend reordering these to ensure they go in the best order.

I can't think of a reason why there would be an optimum direction as
far as the cost of the operation goes. But the optimum direction for
the *result* is to go forward in time (the same order in which commits
happen).

> > For example, if deltify r1000 requires creating of a fulltext of r999,
> > then you'd want to do 1000 *before* deltifying 999.

No fulltexts are created as a result of deltification.

> Using this repository
>
> stress.pl -c -s0 -F10 -D10 -N2 -x100 -W -d -P3 -n40
>
> (that's 40 revisions, 100 files per revision, a small change in each
> 30k file) and comparing
>
> svnadmin deltify -r1:41 repostress
> svnadmin deltify -r41:4 repostress
>
> I find that forward is faster than backward, i.e. 41:1 takes about 50%
> more CPU than 1:41.

That's interesting ... I wonder why. Oh! If you go backwards, you
have to first *undeltify* your "against" nodes so you can deltify your
target nodes. In the opposite direction, your "against" nodes are
always fulltexts. That makes sense. And, fortunately, is the best
direction for later undeltification anyway.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 12 23:12:18 2003