Re: extensible metadata patch

On Mon, 2013-09-09 at 18:17 +0100, Vivek Dasmohapatra wrote:
On Mon, 9 Sep 2013, Colin Walters wrote:

While this would increase the cost of the initial download of a commit
before we can even show them whether or not there's an OS upgrade, if
they do choose to take it, it'd be a lot more efficient than fetching
all of the individual metadata objects.

I think on the whole your current design wins over packed commits
(although of course this depends on the exact ostree usage pattern):

  - Fetching just the metadata is a big win, the user/system can decide
    if the download is one they want/can-afford to download right now.

Ah for "packed" commits I meant just metadata (i.e.
commit/dirtree/dirmeta), not content.

The cost of packing all metadata together is that in a continuous
integration scenario like gnome-ostree, we'd end up duplicating storage
space for a lot of dirtree objects.  Particularly if your repo has a
high branching factor, this could get costly.  Or maybe not...I need to

  - Being able to work out that you only need certain objects (and how big
    they are) based on the metadata alone is even nicer.

Right, definitely!  Handling efficient downloads of both content as well
as metadata is a use case for the static deltas stuff I am slowly
working on ( )

I'll probably defer network efficiency to static deltas.

Anyways, so I pushed that commit patch, let's see if we can rebase and
get both the sizes and gpg integrated.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]