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).
reparenting-one-session-1.patch
Description: Binary data
