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

I (Julian Foad) wrote: > I (Julian Foad) wrote: > 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) And I meant to say, the numbers increased when I applied the attached 'reparenting-one-session-1.patch' which uses a single session instead of two sessions in some of the merge code: 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: 30 (+ no-ops 15) DBG: ... sessions:  8, reparentings: 36 (+ no-ops 21) 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: 36 (+ no-ops 15) DBG: ... sessions:  8, reparentings: 44 (+ no-ops 21) So I won't make changes like that.  In fact, I might do the reverse: look for places where it's already flip-flopping between the source and target trees and would benefit from being given two separate sessions.  I don't know yet if such places are due to changes I made in the recent-ish past; that's possible. - Julian [...] > > 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).