On Thu, Dec 25, 2008 at 4:17 AM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
>> > @@ -520,6 +522,14 @@ svn_ra_serf__get_latest_revnum(svn_ra_se
>> > const char *relative_url, *basecoll_url;
>> > svn_ra_serf__session_t *session = ra_session->priv;
>> >
>> > + /* Using HTTP protocol v2; already got it in the initial OPTIONS
>> > response. */
>> > + if (SVN_IS_VALID_REVNUM(session->youngest_rev))
>> > + {
>> > + *latest_revnum = session->youngest_rev;
>> > + return SVN_NO_ERROR;
>> > + }
>> > +
>> > + /* Fall back to old-fashioned way of getting it. */
>
> Hmm, so won't this return incorrect (old) results if a commit
> occurs between open and get_latest_revnuM? You could argue that
> since svn_client treats ra connections as cheap and disposable
> that's not a problem, but they're not necessarily cheap
> (svn+ssh), and some clients may not be so cavalier...
>
> This especially hurts a client that opens an RA connection and
> then calls get_latest_revnum periodically, looking for a change.
Hmm, this 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.
Greg: you said that the old-fashioned code "can now cache the
youngest rev", but I don't see where that's happening. Is the cached
value somewhere *other* than in the global session_t?
Received on 2009-01-09 18:34:10 CET