Re: Extending ostree's functionality (adding a metadat index)

[Colin Walters <walters verbum org>]

On Wed, 2013-09-04 at 17:34 +0100, Vivek Dasmohapatra wrote:
> > succeeds.  Second, it'd be easier to just pass NULL here, and not clear
> > the error.
>
> Ok. My thought was that at this point we might want to extend
> the error checking to only specifically scrub the "not found" error,
> so if the underlying code threw any _other_ errors we'd still know
> to stop and notify the caller. But I'm ok with not checking if you
> think it's not worth it.

I'd definitely prefer checking only for G_IO_ERROR_NOT_FOUND or so, but:

> Fine by me - I considered this approach originally but I wasn't
> sure you'd want statefiles like that, and it seemed more "bulletproof"
> to me to examine the thing itself directly.

It's worth discussing; the tradeoff with storing the state "externally"
in the remote cache is that if say you fetch the same commit via another
repository, ostree pull won't know it's in a "thin" state.

The two repository case could really happen in practice if say you
have one OSTree repository for public releases, and a separate one
internally for CI/branches etc., and you just sync a subset of commits
from the CI repo to public.  Then a client who had a metadata-only/thin
pull from the CI one, then tried to pull from releases would fail.

Another alternative; name the .commit on the filesystem
like .commit-partial/.commit-thin, and ostree_repo_pull() could
explicitly check for .commit-partial, and assume it has to scan for all
content objects.