Philip Martin <philip@codematters.co.uk> writes:
> "C. Michael Pilato" <cmpilato@collab.net> writes:
>
> > 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.
>
> My understanding of deltification is a little vague. Once a node is
> deltified do subsequent commits or deltifications change it?
A node is always deltified against some other node. Subsequent
commits will not modify nodes that aren't part of that commit.
Subsequent deltifications of successors of the node may or may not
re-deltify that node against a different node, younger than itself,
and generally younger than the last node against which it was
deltified. I say "may or may not" because the node might not get hit in the
skip-delta process. I say "generally younger" because if you can
certainly have a situation where you cause a node N that is currently
deltified against its grand-successor J steps away to be redeltified
against a successor that is < J steps away.
> Can the fs determine that a node is already delitified?
Yes.
> It would be great if "svnadmin deltify -r1:HEAD" could simply skip
> over already deltified nodes,
Actually, it wouldn't. That would necessitate the removal of
skip-delta generation, and would ultimately make the retrieval of
older revisions of the node more costly.
> at present re-running deltification on an already deltified
> repository takes longer than the original deltification.
That's correct. Deltification works its very fastest when the node
you are deltifying is being deltified against a different *fulltext*
node.
That's why I would encourage folks to run 'svnadmin deltify -r REV'
per-commit. Or, if the wanna use a cronjob, they should remember the
ranges they've deltified, perhaps by setting a custom property on
revision 0 of the filesystem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 13 00:06:37 2003