Re: [Gnu-arch-users] Preliminary Arch Cache available

[James Blackwell]

>> I disagree. I think that revision A in the cache should be identical
>> to revision A in the archive. Though I've got more reasons, one
>> reason would be that it may not even be possible to build a fresh
>> cacherev, due to missing information (think a tag of a version in a
>> no longer existant archive).


Tom Lord wrote:
> The cacherev is well (objectively) defined even if your client doesn't
> have enough information to build it.  But if your client does have
> enough info -- why in the world shouldn't it?

Thats my preference. Here's why I prefer it:

If he sticks strictly to caching what's already created, its a very
simple addon. All of the answers on behavior are *very* obvious.

Throwing in local cachereving complicates it a bit. There isn't just
trying to chase down versions in other archives to see if you *can*
build a cacherev. There's other less obvious problems with it too. For
example, now you're talking about trying to guess when the time is right
for a cacherev. If we can't figure that out in the original archive (and
all discusisons point to this), then we can't do it locally as well.

Sure, we can rely on overlysimplistic rules of "oh, then we'll just
cacherev at the start of a version", but those can be oh-so-wrong as
well. All it takes is a little bit of imagination to imagine a large
project that branches early and often. Now, you're back to throwing away
the user's diskspace unnecessarily.

of course, we can tune that, and only cacherev if there are more than X
number of revisions. But that sticks us into the position of
fortuneteller, as we try and figure out ahead of time how large a branch
will grow. 

Sure, we can get around that too, by dumping the question off on the
user: should we automatically cacherev in this archive? Which will lead
to people saying "Hey, that doens't work for me, because in some
branches I do, and in some I don't". At this point we'd have to choose
to either tell 'em to suck it up, or bow to their request, giving them
something they really don't want in the first place, because the
management grows too large.

So the idea has grown from "I know! Since I just downloaded this
revision, lets store it for later" has grown into a much larger *series*
of questions, many of which we have to solve through heuristics. 

But lets take it for granted we could answer all of those questions
satisfactorily. I still think its the wrong answer.

Cached revisions serve their purpose well: They prevent you from having
to make a lot of round trips to build something; instead, you can just
grab "now" from some time ago, and build from there. That saves a lot of
pain and misery, because it takes too damn long to build a working copy
from umpteen bazillion patches which were downloaded at 3kb/sec. 

But on the localfilesystem, we have access to revisions at what could
effectively be called an instantaneous rate. Now, sure. I can hear you
saying "but it takes time to build the working copies, because of all
of the patch applying". Sure it does. But we already solved that problem 
with revision libraries.

Ok. So we can pull revision libraries, right? Not so fast. We're already
addicted to those because if we gave up revision libraries, then we'd go
back to pristines in tree, giving up hardlinking, etc.

So effectively, by turning "hey, lets stash a copy of the revision while
we've got a chance" into a guessing game which won't perform as well as
revision libraries anyways.

Again, its just my preference. I wouldn't roadblock caching because of
this. 


> There are a few intentional acts in arch (commit, tag, import) ---
> lots of other stuff is deterministic on top of those.   Why would you
> ignore that fact?

Pardon? Would you care to rephrase that? 

-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

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