RE: Merge ra-reuse-session branch to trunk or not?

You wouldn't be able to check the id of the old auth baton once the pool is cleaned...

Libsvn_client could do some magic but this would have to be done in every place where we create/fetch Ra sessions. This makes it even more of a hack than the current code, while the idea was to clean things up by moving some of the code in the Ra sessions.
(Thanks autocorrect for capitalizing Ra)

It is possible to attach a pool cleanup handler to see when the auth baton is cleared, but I don't like that solution either.

I agree with Ivan: We should check if the javahl trickery is valid. (We can fix javahl of course, but perhaps other users do the same thing)

We probably never described limitations...

Bert

-----Original Message-----
From: "Evgeny Kotkov" <evgeny.kotkov_at_visualsvn.com>
Sent: ‎19-‎9-‎2015 19:49
To: "Ivan Zhakov" <ivan_at_visualsvn.com>
Cc: "Branko Čibej" <brane_at_apache.org>; "Subversion Development" <dev_at_subversion.apache.org>
Subject: Re: Merge ra-reuse-session branch to trunk or not?

Ivan Zhakov <ivan_at_visualsvn.com> writes:

> Otherwise, here are my ideas at the moment:
> 1. Add svn_client_ctx2_t with svn_client_context_create3() that's
> accept AUTH_BATON as parameter. This will require revv all
> svn_client_*() functions to create new svn_client_ctx2_t() on every
> invocation of deprecated function.
>
> 2. Add svn_ra_set_auth_baton() function to change AUTH_BATON in
> existing RA session. But in this case RA session implementation should
> re-authenticate after every reuse because new AUTH_BATON may have
> different credentials.
>
> 3. Revert r1704048 and wait until next hackathon for better ideas :)

As a random idea:

4. Make each svn_auth_baton_t have a unique ID generated upon creation with
   svn_auth_open(). Place this ID alongside with the baton in the RA session
   pool. Open a new RA session in case the baton's ID does not match the ID
   within the cached session — i.e., do not try to reuse the session if the
   auth baton IDs do not match.

Regards,
Evgeny Kotkov
Received on 2015-09-19 21:17:56 CEST