Hi, I think now is good moment to discuss whether we should merge ra-reuse-session [1] branch to trunk or not: it's better to merge such branch in the beginning of release cycle, to have more time to test and dogfood.
The idea of the branch is pretty simple: add pool of RA sessions in svn_client_ctx_t and use it when we're going to open new RA session in libsvn_client. RA sessions are returned back to RA pool *only* by explicit svn_client__ra_session_release() call. RA sessions *will not be reused* if they are destroyed by APR pool cleanup. Goals of the branch were: 1. Avoid opening many TCP connections and improve merge performance of WAN 2. Avoid opening many TCP connections and improve performance in some non-typical cases like working copy with many svn:externals (issue 3763 [2]) or subtree svn:mergeinfo. 3. Avoid passing RA session around and writing custom code with reparent RA session to interesting and back in libsvn_client. 4. Improve performance of GUI clients that perform several svn_client_* operation using the same svn_client_ctx_t. That branch is complete and ready for merging, but I'm still not sure whether we should merge it or not. Pros: - It reduce number of TCP connection to something like one or two, instead of 10-20 in some cases. - It should theoretically improve performance oven WAN - It allows us write cleaner since we don't manage RA sessions. See patch in [4] as an example how code could change. - Fixes issue 3763 Cons: - In makes behavior less stable. RA session pool doesn't reuse sessions that was unused for some time to avoid timeout issues - There is the chance that we will try to reuse 'broken' RA session due the bug and operation will fail [1] https://svn.apache.org/repos/asf/subversion/branches/reuse-ra-session [2] http://subversion.tigris.org/issues/show_bug.cgi?id=3763 [3] http://svn.haxx.se/dev/archive-2013-06/0164.shtml [4] http://svn.haxx.se/dev/archive-2015-02/0054.shtml -- Ivan Zhakov
