On Tue, Jan 13, 2009 at 3:36 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Ben Collins-Sussman wrote:
>> On Fri, Jan 9, 2009 at 11:33 AM, Ben Collins-Sussman
>> <sussman_at_red-bean.com> wrote:
>>
>>> is an interesting problem. Perhaps we want to distinguish
>>> two sorts of callers:
>>>
>>> * clients who are calling svn_ra_get_youngest_revnum()
>>> * internal serf routines who need to know what HEAD is
>>>
>>> The former audience needs a network request to happen, but the latter
>>> audience is generally fine with using the "latest cached" value. So
>>> I could revert this bit of change which makes youngest_revnum() look
>>> for a cached value, and move that logic into a helper function
>>> instead, used by other serf routines.
>>
>> OK, I've done this in r35220. Serf's implementation of the public
>> svn_ra_get_youngest_revnum() *always* makes a network request, so that
>> there's no chance of getting a stale HEAD value. I created a new
>> internal func which attempts to try the cached HEAD first.
>>
>> Ironically, after all this work, I can't find a single bit of interal
>> serf code that needs to discover HEAD, other than (maybe?)
>> svn_ra_serf__get_dir(). Is that a reasonable candidate for "just
>> used the latest cached value of HEAD"?
>
> No implementation of an RA API should be allowed to use a stale value for
> HEAD. Subversion != svn, and GUI clients that keep the libraries loaded
> (and such HEAD-revision caches populated) should not be cheated of accurate
> information when they hit our APIs. Valid uses of such a cache are strictly
> limited to those which consult the cache *only* after *themselves* first
> refreshing said cache with an actual repository query.
Okay then! So be it. :-)
Received on 2009-01-13 23:13:35 CET