Re: svn commit: r1365324 - reparenting an RA session each time it's used

I (Julian Foad) wrote: > Julian Foad wrote: >> Daniel Shahaf wrote: >>> So... should we revv ra_svn so 1.8 clients/servers can talk to each >>> other exclusively in repos-root-relative paths? >> >> That sounds good to me, but I don't understand the authz impact. >> >> In much of the merge code, it is convenient to carry around just one RA >> session and reparent it as necessary to address (parts of) the source >> and target trees in the repository.  I have been changing more of the >> code to work that way, and would like to continue. >> >> If we can alleviate any ra_svn performance impact by adjusting RA_svn, >> that would seem to be best. Using the attached 'reparenting-monitor.patch' and running merge_reintegrate_tests-10, I found that each of the merge commands executed in that test performs between 2 and 50 reparentings. DBG: ... sessions:  3, reparentings:  4 (+ no-ops  9) DBG: ... sessions:  3, reparentings:  4 (+ no-ops  7) DBG: ... sessions:  4, reparentings: 12 (+ no-ops 11) DBG: ... sessions:  6, reparentings: 22 (+ no-ops 19) DBG: ... sessions:  8, reparentings: 28 (+ no-ops 25) DBG: ... sessions:  2, reparentings:  2 (+ no-ops  7) DBG: ... sessions:  3, reparentings: 12 (+ no-ops 12) DBG: ... sessions:  3, reparentings:  8 (+ no-ops 10) DBG: ... sessions:  6, reparentings: 28 (+ no-ops 19) DBG: ... sessions:  8, reparentings: 36 (+ no-ops 25) > To reduce the load on ra_sv, there's also a coding style change I could > make.  In relatively low-level merge functions, instead of unconditionally > reparenting (temporarily) I could reparent only if the requested URL is > not a child of the current session URL. The numbers did not reduce when I taught some of the code to only reparent if the new URL is not inside the old URL, because nearly all of the reparentings are flip-flopping between the merge source tree and the merge target tree.  That's the worst-case scenario that Bert mentioned. So it seems it is wise to keep two main RA sessions -- one for the merge source tree and one for the merge target tree (in the repo). But what about when we examine paths in the history of the merge source (or target) tree if the source (or target) has been renamed -- we follow the rename, but that means we'll be asking about paths that are no longer within either of those trees. (The 'session root' concept is strictly by path, not by node object). - Julian