View Ticket
Ticket Hash: c9d454153eea9690a93fcdddb18730b381403a25
Title: Bad find_filename_changes
Status: Fixed Type: Code_Defect
Severity: Priority:
Subsystem: Resolution: Fixed
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".