[MERGE][bug #120697] Don't force http cache revalidation

John Arbash Meinel john at arbash-meinel.com
Tue Nov 20 20:37:19 GMT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> Vincent Ladeuil wrote:
>>     aaron> It was needed because of broken proxies that would return stale data,
>>     aaron> causing breakage in fetch, unless we did that.
> 
>> So the bug report is wrong and we shouldn't fix that behavior or
>> not ?
> 
> To me, it's a tough call.  You get really strange errors when your proxy
> is returning stale data, so I'd be inclined to leave it on by default,
> and allow people to disable it.
> 
> Fortunately, packs don't reuse names, so breaking fetch is much less of
> a concern.
> 
> Aaron

Also, I think we are better about making sure we fetch specific data.

Back when we used Weaves, we assumed that a referenced weave would contain
everything we needed. So we just downloaded the whole file, and pushed it into
the local repository (overtop of whatever we used to have).

With knits, we are expecting a specific set of revisions. So if the .kndx
doesn't have them (because it was being cached), then we would know that
something was wrong. So we should abort, rather than copying broken data. (If
the .knit data wasn't downloaded, we should likewise be aware that something
was wrong and abort.)

As I mentioned in the other email, what can happen is a branch won't look like
it has been updated. But that is a relatively minor thing.

I see that we could do a few things.

1) Default to allowing caches to work transparently.
2) Allow users to add a BZR_NO_HTTP_CACHES=1, which will set the Pragma's to
force a revalidation.
3) Get extra fancy and supply the Pragma for files which are small and don't
really need to be cached. For example .bzr/branch/last-revision. And maybe the
.kndx files.
So the .knit data would still be cached, but we would be sure to have the
latest indexes. We would still need to be safe in the presence of incomplete
data (we know that we should have bytes 1000-2000 but we only get 1000-1500
because the cache didn't see the rest.) But we need that anyway.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQ0V/JdeBCYSNAAMRAqSRAKCTbjHB5iisWX3JOWMjeg6PldTIjACghG/h
mvsu+GkaNu2N7r2UhNIHEV8=
=4sFC
-----END PGP SIGNATURE-----



More information about the bazaar mailing list