> -----Original Message-----
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: vrijdag 31 augustus 2012 14:30
> To: C. Michael Pilato
> Cc: Justin Erenkrantz; Subversion Development
> Subject: Re: [PATCH] Make ra_serf be more aggressive about closing
> directories in update
>
> On Fri, Aug 24, 2012 at 5:56 PM, C. Michael Pilato <cmpil...@collab.net>
> wrote:
> > On 08/10/2012 06:20 AM, Justin Erenkrantz wrote:
> >> FWIW, last week, I went down the path of trying to optimize the 'ls'
> >> client path - which issues two OPTIONS requests...which is kinda
> >> silly. but to remove it, requires that the RA open call also return
> >> the youngest revision. I rev'd all of the RA layers, but then got
> >> stuck in a maze of twisty calls inside libsvn_client to try and use
> >> that revnum to skip the later call which invokes OPTIONS again...I
> >> should probably post that incomplete patch before moving on to
> >> something else. =)
> >
> > If it makes you feel better, I've been down this road before, too. :-)
> >
> > One thing that occurs to me as possible solution is to add a flag to
> > svn_ra_openX() which instructs the RA layer to immediately negotiate the
> > current youngest rev and then freeze that snapshot of the repository for
> the
> > duration of the RA session's lifetime. The client layer alone knows whether
> > the high-level operation it is performing would be effected by additional
> > commits to the repository. So for read-only operations, the clients would
> > pass this flag to the RA open stuffs, and the RA layer would cache the
> > youngest-rev. Future calls to svn_ra_get_latest_revnum() on that session
> > would always return the cached value. Other RA calls that allow you to use
> > SVN_INVALID_REVNUM to mean "HEAD" would also use the cached
> youngest-rev.
> >
> > Is that crazy?
> >
> > My one concern is that it might negatively effect code clarity. If I see
> > svn_ra_get_latest_revnum(ra_session, &youngest, pool) in the client
> code, I
> > can't immediately tell if that function call will get the *realtime*
> > youngest revision or the frozen snapshot revision. I'd need to find the
> > ra-open call to see if that special flag was provided.
> >
> >
> > -- C-Mike
> >
> > PS: Going really nuts, we *could* allow the RA session to "peg" not merely
> > the current HEAD, but any arbitrary revision as the youngest revision the
> RA
> > session will be allowed to recognize. But I can't quickly come up with a
> > good reason for doing that.
> >
> For me it looks like abstraction leakage. Better solution would be
> create new object like svn_client_ra_session_t() and store
> cached/negotiate latest revision here, while extend
> svn_ra_session_open to return youngest revision if requested.
We could just rev the function that retrieves the last revision to allow
telling it that returning a cached value is ok. (Or add a different function
for the potentially cached value)
Creating the sub-ra_sessions is probably too much for this optimization, but it
could be useful for other things too.
Bert
