Reverse order of changesets in quick succession

[Matt Shin]

Having committed a few changesets in quick succession (all committed in the same second) in a Subversion repository, I have discovered an odd behaviour in the Trac timeline, where the events are sorted in ascending order, e.g.:

10:58 Changeset [4] by matt 10:58 Changeset [5] by matt 10:58 Changeset [6] by matt

Normally, I would expect things to be arranged in the usual reverse chronological order, like:

10:58 Changeset [6] by matt 10:58 Changeset [5] by matt 10:58 Changeset [4] by matt

An oversight?

[hyuga <hyugaricdeau@…>]

I'm confused… maybe this is a stupid question, but how did you manage to commit multiple changesets in the same *second*?

Regardless, I would imagine this would more likely be a bug in Subversion than Trac, but I don't know…

[Matthew Good]

There is no defined ordering for timeline events that have the same timestamp. You can see discussion of this on the MailingList here: ​http://groups.google.com/group/trac-dev/browse_thread/thread/1ac11d8838f7f77e/b8b665ac1bffcadf?lnk=gst&q=heap&rnum=1#b8b665ac1bffcadf

I mentioned using the title, but besides the changesets it doesn't seem to make sense to order events in reverse order by title. I'll have to give this some thought.

[Matt Shin]

Replying to hyuga <hyugaricdeau@gmail.com>:

I'm confused… maybe this is a stupid question, but how did you manage to commit multiple changesets in the same *second*?

Regardless, I would imagine this would more likely be a bug in Subversion than Trac, but I don't know…

I did several cheap copies and directory creates using a script. It manages to do 3 commits in the same second.

[Christian Boos]

web_ui.py

@@ -146 +146 @@
                 self._provider_failure(e, req, provider, filters,
                                        [f[0] for f in available_filters])
 
-        events = sorted(events, key=lambda e: to_timestamp(e.date), reverse=True)
+        events = sorted(events, key=lambda e: e.date, reverse=True)
 
         # prepare sorted global list
         if maxrows:

should be enough to fix this issue. to_timestamp convert to seconds, which looses the subsecond information present in the original datetime objects (and initially provided by subversion dates as well).

That should be enough for all but the cases where the times are exactly the same (i.e. same microsecond), and for those situations the order doesn't really matter.

[anonymous]

Replying to cboos:

That should be enough for all but the cases where the times are exactly the same (i.e. same microsecond), and for those situations the order doesn't really matter.

Thanks for the simple and quick fix. I don't think we'll ever manage to commit in the same microsecond (unless we set the revision property "svn:date" manually…).

[Matthew Good]

Ah right, I forgot to remove the to_timestamp() call which was unnecessary when using the sorted method. It's been done in r5209.

[Matt Shin]

Replying to mgood:

Ah right, I forgot to remove the to_timestamp() call which was unnecessary when using the sorted method. It's been done in r5209.

Since you have committed the fix to the source:trunk​, I guess it will be scheduled for milestone:0.11. I hope you don't mind me setting the milestone for you.

[Emmanuel Blot]

See also related ticket #5819