On Fri, Aug 24, 2012 at 9:56 AM, C. Michael Pilato <cmpil...@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
