[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question on copies implementation

From: Andrea Aime <aaime_at_openplans.org>
Date: 2006-11-08 19:22:44 CET

C. Michael Pilato ha scritto:
> Andrea Aime wrote:
>> One thing I'm sure I do not understand is the relation between diffs
>> and branches. On the diff section you say that you store reverse
>> diffs and only the latest revision is a full copy.
> That's true for the BDB backend; the FSFS backend stores forward deltas.

First of all, thank you very much the the detailed explaination.
Now, I'm really curious about forward deltas: does this mean that
you have to sum all all diffs in order to rebuild the last revision
of a certain branch?
In my research I've found system that do use forward changes, but do
not do deltas (database records are usually small), so the process
or rebuilding the last revision from the initial copy is just a
selection, with no computation.
How does svn work with in this respect?

>> Moreover, on the branch/tag sample the cheap copy is defined as a
>> simple pointer to the previous revision.


> That's not quite correct. It's complicated. If you make a branch (from
> HEAD-at-the-time) and commit a change to a file, then (in a simple
> world) file-on-branch will be fulltext, and its predecessor (which is
> file-on-truck) will be deltafied against that new fulltext. But the
> next time you change file-on-trunk, you now have two fulltexts.
> ,---[B]
> /
> ------[A]-------------[A']
> t0 t1 t2
> At t0, A is a fulltext. At t1, you've copied A to B; B is now a
> fulltext, and A is a delta against B. At t2, A' is a new fulltext, A is
> now a delta against A', and B remains a fulltext. So, in the general
> case, there is a fulltext at the tip of every branch in a file's version
> history.

What happens if you do the branch, perform no changes on it, and then
change trunk? A full text is created anyways on the branch?

> Now, reality is more complicated, because we have this "skip delta"
> concept in the mix. With "skip deltas", we re-deltify ancestors of a
> new node revision against the new fulltext (so we reduce the number of
> deltas that need to be applied to reconstitute the fulltext of a older
> revision). For example, if I change file-on-trunk, we re-deltify its
> 4th-, 8th-, 16th-, and 32nd-level ancestors against itself (or something
> like that).

Ah, interesting. So when you do want the, say, 6 level ancestor, you sum
the 6th, 5th and 4th delta, and then do the jump, right?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 8 19:23:25 2006

This is an archived mail posted to the Subversion Dev mailing list.