Re: [Gnu-arch-users] caching revisions

[Aaron Bentley]

David Allouche wrote:
> > 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.

Yeah, it's a very thin pipe.  In this case, since the implementation in 
1.2 and 1.2.1 is busted, I figure it's important to consider the 
implementation level.  (and cacherevs contain inode-sigs, which are 
non-source files, so you could say they're *still* busted)

> 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.

tla's usual behavior is to do what you tell it to, even if it's probably 
a bad idea.  It doesn't usually try to outsmart the user.  In this case, 
uploading a new cacherev is unlikely to be harmful, and possibly useful.

> 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.

People who want to avoid double-cachereving can use the cachedrevs 
command to see if it's already been cachereved.

Data corruption is the main reason I see for it.  There is currently a 
very simple way to produce a corrupt cacherev: invoke tla cacherev twice 
using 1.2, 1.2.1 or a derivative.

Aaron