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 <cmpilato_at_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.

-- 
Ivan Zhakov