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.
-- Ivan Zhakov
