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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1022879
Received on 2009-01-13 22:37:27 CET