#5819 closed defect (fixed)
Timeline events with same exact date show up backwards
Reported by: | Tim Hatch | Owned by: | Tim Hatch |
---|---|---|---|
Priority: | normal | Milestone: | 0.11 |
Component: | timeline | Version: | devel |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I've encountered this using external tools to modify svn repositories. When the timestamps are the same second, revisions are displayed newest-last in the timeline.
I'm attaching a fix that works for me. I'm not using any esoteric timeline event providers, so I'd just like some verification this doesn't break anything for other users.
Attachments (1)
Change History (5)
by , 17 years ago
Attachment: | timeline-reversed.diff added |
---|
comment:1 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
After discussing with Coderanger a bit on IRC, he pointed out this was actually an issue with the svn backend generating changesets in the wrong order. get_changesets() should generate changes in reverse-chronological order, and the sort done at the timeline level should leave alone whatever order that is in case of a tie on timestamp.
Hopefully fixed in r5891
follow-up: 4 comment:3 by , 17 years ago
Nice catch, I didn't notice that ticket even with searching. In my case they were committed to a tweaked repository using another vcs so they had exactly the same timestamp, and still triggered the #5153 issue even with its fix. r5891 makes the get_changesets order start with youngest_rev first, which is consistent with the order we'd like them to display in the timeline (in case of exact ties…).
comment:4 by , 17 years ago
Replying to thatch:
In my case they were committed to a tweaked repository using another vcs so they had exactly the same timestamp, and still triggered the #5153 issue even with its fix. r5891 makes the get_changesets order start with youngest_rev first, which is consistent with the order we'd like them to display in the timeline (in case of exact ties…).
Ok, thanks for the details.
Diff against r5887