Re: Thoughts on a new network repository mode: subtrees

[Colin Walters <walters verbum org>]

On Mon, Oct 20, 2014, at 10:02 PM, Colin Walters wrote:
> Maybe in the priority list, the highest here is strong support for local
> mirrors.  We have that now, but there are still some gaps in that we
> don't support traversing history yet.

That's done now with https://bugzilla.gnome.org/show_bug.cgi?id=739240

So, Giuseppe has picked up the static deltas work in
https://github.com/GNOME/ostree/pull/16

Should we move forward with the branch as is, without any support for
intra-file
diffs?  The thing I struggle with is that the intra-file diff
cost/benefit comes
down a lot to the content type.  Unless we do something like Courgette
we're not going to really win on ELF binaries (I don't think bsdiff is
worthwhile on ELF versus a simple tar-of-new-content, as static deltas
basically are now).

Then the other case I bought up is non-executable content embedded
inside
executable files.  This happens with GResource, as well as things like
Python
docstrings in the bytecode.


FInally, I'd like to consider the virtues of static deltas versus
subtrees.   The
subtree approach would allow migration between unrelated moving versions
- for
example, switching from Fedora 21 to rawhide.  Yes, you'd end up
basically
downloading all the content, even if you happened to have a lot of
common
objects between them.

Subtrees would be a decent "general purpose" system - they'd be a
similar
set of tradeoffs as package systems, except you'd still have
"image-like"
replication.

(If one keeps going down that path though, the question arises "why not
 compose trees client side" - and that's a worthwhile discussion, but
 for the purposes here let's assume that the OSTree consumer wants
 binary-level replication)