[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r34914 - branches/http-protocol-v2/subversion/libsvn_ra_serf

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 14 Jan 2009 08:22:59 -0500

Ben Collins-Sussman wrote:
> On Tue, Jan 13, 2009 at 8:10 PM, Justin Erenkrantz
> <jerenkrantz_at_apache.org> wrote:
>> On Tue, Jan 13, 2009 at 5:23 PM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
>>> In what universe does "latest" mean "the value I cached when you
>>> created this ra object an hour ago"?
>> No matter what value you fetch from the server, excepting that it
>> represents a lower-bound on the true value, the value *must* otherwise
>> be considered immediately invalid anyway. I believe whether it's
>> out-of-date by an hour or a minute or a second is largely immaterial
>> in the larger scheme of things. If code is making assumptions that
>> the latest revision value is accurate, then there's likely deeper
>> issues in the code. -- justin
> Eric already gave (IMO) a valid use-case -- a daemon which opens an
> ra_session and "polls" the repository every 2 minutes. Like a
> buildbot, for example. There's nothing pathological about such a
> program: it's not depending on the assumption that each polled value
> can't possibly be out-of-date at all, but it *is* assuming that it's
> not more than 2 minutes out-of-date, which is completely reasonable.

Agreed. Most of our RA operations are pegged to a revision anyway, and so
it is common for the client layer to first ask "what's the HEAD revision?"
and then peg its operations to that revision. This ensures a mostly static
(modulo revprop changes) concept of HEAD through the lifetime of the
higher-level operation. This empowers the client layer to decide when it
needs to refresh its knowledge, and alleviates the need for an RA-based
cache of HEAD altogether. That, to me, is the right balance of precision
and "obnoxia", if you will.

Take a look at our own use of the RA APIs. We don't often pass
SVN_INVALID_REVNUM (which means "HEAD" in that context) to the interfaces,
because we generally want to evaluate HEAD once and then use that hard
revision throughout the high-level op. And when we *do* use
SVN_INVALID_REVNUM, it's generally because we're trying to do a quick
out-of-dateness check as an early out to a commit-type operation, and a
cached value of HEAD in those situations damages the effectiveness of those
time-saving sanity checks.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
Received on 2009-01-14 14:25:45 CET

This is an archived mail posted to the Subversion Dev mailing list.