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

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.

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