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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-08-24 15:57:09 CEST