On Fri, Aug 24, 2012 at 9:56 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> If it makes you feel better, I've been down this road before, too. :-)
*grin*
> 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?
I didn't go so far as to freezing the session, but it's not completely
bonkers. =) I thought about it for a half-a-second and thought that
pegging the youngest rev to the session might have some awkward
side-effects - mainly due to a single session that does a youngest,
sends a commit, and then wants the youngest rev. That could be
badness...though I guess in theory the client side could invalidate
its cache when it does a commit...but...awkwardness lies behind that
door...
> 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.
Yup. That's why it's only moderately bonkers.
I think if we were to really do this, we should have a proper API and
not slipstream it into the open call. (Perhaps get_latest_revnum
could grow a parameter specifying if its okay to utilize a cached
value??)
> 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.
As Daniel pointed out, that capability would help some awkward
scenarios that would likely simplify some of our automated test
invocations. -- justin
Received on 2012-08-25 01:08:59 CEST