Re: [Gnu-arch-users] archive-mirror not pushing cacherevs?

[James Blackwell]

In lists.arch.users, Tom Lord(?) wrote:
>
>     > From: Johannes Berg <address@hidden>
>
>     > Therefore, I called
>     >         tla cacherev MetaNet--main--1.0--base-0
>     > which worked fine.
>     > Now, however,
>     >         tla archive-mirror
>     > does nothing.
>     > Is that expected behaviour? I'd regard it as a bug ;)
>
> Expected, actually.  I'm assuming that the mirror already has base-0.
> You can cacherev directly to the mirror.  (Also see asuffields rsync
> hacks.)

This works if you own the mirror. I've had to satisfy at least four
requests to remirror because of this specific issue.

Of the five or six requests I've had, they typically go along these
lines (there's a reason I'm giving this story):

Requestor: Hey jblack. I've done (either something non-arch-like or a
           cacherev of an early revision). Your mirror is out of date.
           I wouldn't have to bother you if you gave me write
           permissions to your mirror.

Me       : Sorry. Things would quickly get out of hand if I had to 
           manage permissions for 65 archives spread across 20-30
           people.

Requestor: Then how about you (soft|hard) link your mirror of my
           archive to my sourcecontrol account?

Me       : Sorry. I'm not going to do that either. That would give sc 
           members special preference over non sc members. I really 
           want to treat every archive as identically as possible so
           that I don't have to track 40 archives of one type, 15 of
           another type and 10 of yet another type.

           Your archive is remirrored.

Requestor: Thanks.
           [requestor seems to be much more careful to not repeat what
           he did last time]



Now, why is this happening? This is happening because users have gotten
into the *really* bad habit of "going back in time" and cachereving old
revisions, editing patch logs... you name it. This is in direct opposition
to one of the cardinal rules of arch: "You can not go back in time."

This promise is actually a two way promise. Arch promises the user that
it won't go back and muck with old data, and the user promises to not
muck with the data behind arch's back. If this promise is broken, we
start to wander into undefined territory (bad signatures, patches that
no longer apply between revisions, etc).  If an exception to that
promise is made in either direction, then the guilty party is obligated
to ensure that the data remains consistant. Failure to keep that
promise, and failure to keep that obligation, means that an archive
becomes damaged.

Of the many problems that an archive (or mirror) can have, a missing
cacherev is pretty darn trivial. Even I'll admit that. However, we're
still looking at an inconsistancy, as a mirror missing a cacherev that
is within the primary archive is now only a *partial* mirror of that
primary archive. Barring semantics, a mirror is supposed to be an exact
copy of something else. But we've broken that promise by letting the
user to back in time and cacherev and old revision.

The result of breaking this promise quickly becomes evident. After the
original archive goes back in time and cacherevs, its children (the
mirrors) become inconsistant until either A) the parent is remirrored or
B) The user copies over the cacherev (!SHUDDER! The user shouldn't be
screwing around in an archive!!!). This wave of poor/improper behavior
continues to wash over other archives as mirrors are updated and mirrors
of mirrors are updated.

So what are we to do? 

Well, we've got two other choices. We can either keep our promise to the
user ("Never go back in time") or we can keep our obligation to preserve
consistancy. 

If we keep our promise to the user, we only allow cacherevs of the
current version. This is pretty simple, and is very, very consistant
with everything else arch does. However, its probably not what most
people want. Users would probably just not be happy saying "I forgot to
cacherev base-0, so I'll cacherev patch-8".

That leaves us with our other option. We (arch) keep our obligation to
maintain consistancy, and we somehow find those missing cacherevs and get
them into the mirror.

So, with an unpalatable promise and a seemingly impracticable
obligation, we are truly behind a rock and a hard place.

However, I've done a little thinking about it and these two possible
solutions come to mind. I leave it up to brighter people than I whether
either of these is practical

A) With each revision, we annotate in the revision what the last
   cacherev was. arch can check that cacherev against the most recent
   cacherev that exists in the mirror. If it comes across a patch that
   says it has a newer cacherev than is in the mirror, then perform the
   cacherev on the mirror. However, we would have to set this up so that
   multiple new cacherevs could be recorded in a patch.

B) When the user cacherevs a patch, he also performs an essentially
   empty commit that has for its only purpose to note the existance
   of a new cacherev.

-- 
James Blackwell      Using I.T. to bring more             570-407-0488
Owner, Inframix      business to your business     http://inframix.com

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400