Edgewall Software

Opened 14 years ago

Last modified 13 years ago

#9205 new enhancement

Make the timeline threaded

Reported by: r.sokoll@… Owned by:
Priority: normal Milestone: next-major-releases
Component: timeline Version: 0.12dev
Severity: normal Keywords: timeline, threads, pushlog
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:


From a little dicussion in trac-users, it came out that it might be a good idea to have a threaded timeline with the possibility to expand/collapse threads. This would make the timeline less noisy, especially on busy timelines.

What I mean here is something like (expanded view):

  Ticket #123 created by
  Ticket #122 created by
  Ticket #100 closed by
    Ticket #100 updated by
      Ticket #100 created by
  Ticket #121 created by 

Or a collapsed view:

  Ticket #123 created by
  Ticket #122 created by
  + Ticket #100 closed by (2 more events)
  Ticket #121 created by

And if you click on the plus sign at #100, the view gets expanded. We already have this in TracBrowser.

The user should be able to configure this behaviour in her/his preferences.

Attachments (0)

Change History (3)

comment:1 by Christian Boos, 14 years ago

Milestone: 0.13next-major-0.1X

0.13 might be the milestone in which this gets implemented, and although I already expressed support to the idea of a threaded timeline on the Trac-users list, I can't promise anything for 0.13.

We'll try to be much more conservative about assigning tickets to version milestones, for the next milestones. When one of the Trac developers assigns it, it should really mean he's reasonably confident he can do it. Otherwise, when we simply think it's a good idea and it would be nice to have it as early as possible, we'll use the next-major/next-minor… milestones for that.

This workflow will help us to avoid having to constantly move tickets from one milestone to the next, and at the same time have a better overview of what's really planned for the immediate next release.

comment:2 by Christian Boos, 14 years ago

For folding changesets, they could be grouped as being part of the same push operation, assuming the hooks would notify us from an incoming sequence of changesets. It seems the trac-admin changeset added command already has the adequate call convention:

changeset added <repos> <rev> [rev] [...]

    Notify trac about changesets added to a repository

    This command should be called from a post-commit hook. It will trigger a
    cache update and notify components about the addition.

To which we should perhaps add the user who did the push. We would then need to have a way to convey that information further.

See also: Mozilla's Mercurial pushlog, SonicHg's pushlog, Gitorious

comment:3 by Christian Boos, 13 years ago

Keywords: pushlog added
Version: 0.12dev

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.