Re: [Gnu-arch-users] Some issues

[Tom Lord]

    > 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.


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.

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:

  1) User's with "complete histories" (no danger of losing remote
     archives) can just use xdelta if they choose.

  2) User's committing or mirroring over thin pipes can just pass
     the smaller xdelta changesets (again, if they have enough history
     information) and, if desired, then build the non-xdelta
     changesets at each end-point.

-t