Re: [Gnu-arch-users] Some issues

[James Blackwell]

>
>     > From: Florian Weimer <address@hidden>
>
>     > * Tom Lord:
>
>     > >     > From: Florian Weimer <address@hidden>
>
>     > >     > No, my complaint was that some file types for which history can 
> be
>     > >     > stored efficiently, but tla fails to provide that feature (which
>     > >     > translates to "not being able to store them at all" in some 
> cases).
>
>     > > Again, you are confusing archival with revision control.
>
>     > Archival is a necessary precondition for quite a few revision control
>     > applications.  
>
>     > Maybe you can avoid it in a few special cases (and other
>     > features, such as merge tracking, are more important there), but
>     > my experience is that archival is sometimes required.
>
From: Tom Lord <address@hidden
 
> Archival is a necessary precondition for quite a few revision control
> operations, sure, but so is inexact patch application.  You can't do
> inexact patch application of an xdelta (or similar binary-file delta)
> in any meaningful sense.

In all fairness, isn't there more than one revision control system that
is testing this assumption by only allowing exact patching? 

> I think what we've recently settled on, though, is to let users make
> the various trade-off choices.    We can fairly trivially make it
> possible to use xdelta for binaries.   I'm satisfied with the design
> we have for that now:  users will be able to commit xdelta revisions
> or regular revisions and an archive can contain both kinds for a
> single revision.   Either can be derived from the other (given enough
> history) and so we'll wind up with properties like:

I think that carrying both types of revisions is a mistake. There are
*two* motivations behind xdelta for binaries. One is to save pipe; the
other is to save disk space. If we keep the old style revision around,
no space is saved. It only makes sense to keep both kinds of revisions
if we're just temporarily carrying both kinds of revisions as a migration
plan for our users.

Sure, I know your usual argument -- "disk space is cheaper all the
time". But that same argument _applies_to_pipe_ as well. Once upon a
time, people used 110 baud accoustic modems. These days, developers with
cablemodems providing *millions* of bits per second is common.


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400