Fossil SCM
If same file is checked in twice, the second time is lost in the file's timeline
d26a9d9e2be7290…
· opened 11 years, 5 months ago
- Type
- Code_Defect
- Priority
- —
- Severity
- Minor
- Resolution
- Fixed
- Subsystem
- —
- Created
- Oct. 19, 2014 12:27 p.m.
When a file was checked in 2 different times (for example: artifact e1b4641cb was checked in here 1eb438d61a and merged to trunk at ec81aee915, and a second time here 77f53423ae) we can end up with a wrong timeline, like this: [http://www.fossil-scm.org/index.html/finfo?name=src/import.c&a=2013-10-06&b=2014-08-16]
In that timeline, there is a fork in the trunk based at ec81aee915, while in fact the correct sequence of events was that the same file was checked in again between the two "heads" of the trunk (at 77f53423ae). Both the second checkin of the file and the linearity of the trunk timeline are missing from that page.
Comments (2)
When a file was checked in 2 different times (for example: artifact e1b4641cb was checked in here 1eb438d61a and merged to trunk at ec81aee915, and a second time here 77f53423ae) we can end up with a wrong timeline, like this: [http://www.fossil-scm.org/index.html/finfo?name=src/import.c&a=2013-10-06&b=2014-08-16]
In that timeline, there is a fork in the trunk based at ec81aee915, while in fact the correct sequence of events was that the same file was checked in again between the two "heads" of the trunk (at 77f53423ae). Both the second checkin of the file and the linearity of the trunk timeline are missing from that page.
Seems to be fixed by [65aa10f97c25606cdc100a73dfa50a81520a31d1]