|Last Modified:||2011-01-04 14:00:29|
|Version Found In:||[79b7902cdd]|
While investigating [74413366fe], we came up with an example where we found a bad behaviour of find_filename_changes. Notice:
[llbatlle@comanegra:~/tmp/merge2]$ fossil test-shortest-path 3f670219 2d34c3f538 1: 3f6702192edd 2011-01-04 09:43:22 is a parent of 2: 2d34c3f5389e 2011-01-04 09:43:39 [llbatlle@comanegra:~/tmp/merge2]$ fossil test-shortest-path 2d34c3f538 3f670219 1: 2d34c3f5389e 2011-01-04 09:43:39 is a child of 2: 3f6702192edd 2011-01-04 09:43:22 [llbatlle@comanegra:~/tmp/merge2]$ fossil test-name-changes 3f670219 2d34c3f538 [a] -> [c] [llbatlle@comanegra:~/tmp/merge2]$ fossil test-name-changes 2d34c3f538 3f670219
Notice how the name change is taken in one direction, and not in the other. Those are direct commits, no merges involved.
The problem is in the line of find_filename_changes()
for(p=bisect.pStart->u.pTo; p; p=p->u.pTo)
This always skips the first checkin of the chain, while it should be skipped only if it is a parent of the next commit. Similarly, some commits (parent of both From and To) should be skipped as well.
The trick is that the checkin id always refers to "AFTER applying the checkin".
- filename_changes_checkins.patch [download] added by anonymous on 2011-01-04 10:42:00. [details]