[Gnu-arch-users] Re: RFC: arch protocol, smart server, and tla implementation prototypes

[Chris Gray]

On 5 Feb 2004, Aaron Bentley wrote:
> Chris Gray wrote:
>> I'm arguing against the creation of a smart server I guess.
>> Currently, when you commit a patch in arch, it is like you are
>> adding a new element to a linked list.  I'm saying that we could
>> change the data structure to a skiplist and keep the dumb server.
>> All of the summary deltas and data structure maintenance would
>> happen client side.
> Okay, I see what you mean now. base0 -> patch1
> patch1 -> patch2
> patch1-> patch3
> base0->patch4
> etc, etc.
>
> Let's assume that some changes accumulate, (changes made to
> different parts of files), and some do not (changes made to the same
> part of the file). Therefore this approach will increase the storage
> space.  It will store some of the differences between base0 and
> patch1 twice, and store some of the differences between patch1 and
> patch2 three times.

Yes, as I have said, the archive size should grow at a rate on the
order of n log n (where n is the number of changesets).

> It will reduce the amount of data need to produce a revision,
> because some changes do not accumulate.  Also, as the amount of
> change grows, hunks can be merged, reducing the overhead.
>
> To produce deltas from previous versions, we'll need the ability to
> compose changesets.  The alternative is to build the from-revision
> as necessary, which would be quite burdensome.

Yup.  Or if the committer has a revision library, it would probably be
trivial (though my knowledge of revlibs is pretty weak).  This is
mostly an optimization for people that are doing gets (or replays)
that have lots of patches.

> Committing with powers of two has similar properties, but I think
> power-of-two would be more predictable and verifiable.

I think the problem here is that when you pass a power of two, the
root of the tree changes, which I would imagine would be a bit of a
hassle.  But yeah, it would probably be just about the same.

Cheers,
Chris