Re: [Gnu-arch-users] caching revisions

[David Allouche]

On Thu, 2004-10-14 at 19:26 -0400, Aaron Bentley wrote:
> David Allouche wrote:
> > I would also have made cacherev (resp. uncacherev) fail when the the
> > cachedrev is present (resp. missing) but it seems that's not the
> > convention in tla.
> 
> I don't understand what you mean by resp.

Sorry, that is a form of compression I learnt about in math classes, and
that I have abused out of laziness, "resp." means "respectively". That
would expand to something like:

        I would also have made cacherev and uncacherev fail when the
        cacherev is already present (for cacherev) or missing (for
        uncacherev).

> > Ever since tla 1.1, cacherev (resp. uncacherev) is considered idempotent
> > and silently succeeds if the cachedren is already present (resp.
> > missing).
> 
> In 1.1, I assume cacherev wasn't literally idempotent-- it did upload 
> new cacherevs which should have been equivalent to the previous ones. 
> In 1.2, checksums were introduced, so it was no longer idempotent in any 
> sense.

Yes, it's not literally idempotent if I do not qualify further what I
mean. Sorry, I have forgotten the importance of being explicit and
unambiguous in mailing list discussions.

I meant that cacherev and uncacherev are considered idempotent from the
Arch abstraction standpoint. The fact that cacherev files are not
bit-to-bit identical after a redundant cacherev is irrelevant at the
abstract level, that's an implementation detail.

Since these functions are defined as idempotent, redundant invocations
do not cause errors, and any effect they have should not be observable
without crossing the abstraction barrier (e.g. reading the actual bits
in the archive).

> As I mentioned to Robert, my preferred solution would be to make 
> double-cachereving upload a new cacherev and update the checksums 
> properly.

Whether to upload a new cacherev and update checksums or to silently
ignore the redundant command is an implementation choice.

The only use case I see for your choice is to overwrite a somehow
corrupted cacherev (maybe because a transfer was interrupted). In all
other cases, overwriting the existing cacherev would yield no observable
benefit at a significant cost.

If there is no way to get a corrupted cacherev short of media failure,
intentional tampering, or changing history, then the most efficient
solution (silently ignoring the redundant command) should be chosen.

-- 
                                                            -- ddaa