Phantom changesets in timeline

[Mikhail Gusarov]

Two phantom changesets appear in timeline view when TracBzr is in use:

19:08 Changeset [null%3A] by
--
19:08 Changeset [current%3A] by
--

[Jelmer Vernooij (jelmer)]

Also occurs on the ctrlproxy bugtracker (http://bugs.bitlbee.org/ctrlproxy/)

[Scott Finman (scott-aocdesigns)]

Can confirm this as well on Trac 0.10.3 and the current main branch of Trac-Bzr. Has anyone come across a work-around?

[Toshio Kuratomi (toshio)]

Just began noticing the [current%3A] phantom on these two timelines::
  https://hosted.fedoraproject.org/projects/packagedb/timeline
  https://hosted.fedoraproject.org/projects/python-fedora/timeline

The most problematic thing about this is they have the current time. So whenever an RSS feed of the timeline refreshes it shows that there's been a new commit.

[Toshio Kuratomi (toshio)]

The revisions themselves seem to be intentional::

  Bogus changesets
  ----------------
  This plugin introduces the bogus changeset "current:", which is used as
  the last-revision for directories that are not branches. It also provides
  "null:", which is part of Bazaar's theoretical model, but usually hidden.
         -- From the trac+bzr README

However, there are two things that still seem like bugs:
  1) trac+bzr should display "current:" instead of "current%3A". Somewhere in the code, the revid is being urlencoded once too often. This is further supported by the URL's on the timeline page::

     <a href="/projects/python-fedora/changeset/current%253A">
     <a href="/projects/python-fedora/changeset/python-fedora-devel%2C54">

  You can see that the current: changeset has been urlencoded twice (':' => '%3A' => '%253A') whereas the normal changeset has been encoded once: (',54' => '%2C54')

  2) The timestamp of the change has the annoying property I stated before of always being the current time thus cluttering RSS feeds with junk. backend.py:BzrChangeset::__init__() should be changed to take the timestamp of the closest revision instead of the current time.

[Toshio Kuratomi (toshio)]

Here's a patch that fixes #2 for 'current:'

For 'null:', it also establishes a stable timestamp but I noticed that 'null:' is set to link to 'current:'. The README doesn't tell me enough about what 'null:' means to know if that's correct or not. If it's not correct, the code in backend.py:BzrRepository:next_rev() would need to be changed.

[Toshio Kuratomi (toshio)]

And here's a patch that fixes #1.

[Daniel Nyström (speakman)]

This is still not fixed in trunk.

[Arvid Norlander (vorpalblade)]

Well the patch did work for me, however, it seems like no developer want to use it in their branch? I don't know python, otherwise I would start a branch myself.

[Jelmer Vernooij (jelmer)]

Making the timestamp fall back to the timestamp of the closest revision is incorrect - it should rather use the timestamp of the latest working tree change.

[Arvid Norlander (vorpalblade)]

The problem with that is that for my setup trac-bzr is set to use the repo, there could be several different working trees under that, also in my case, none has any working tree.

[Jelmer Vernooij (jelmer)]

If there is no working tree, there should be no "current:" revision either.

[Aaron Bentley (abentley)]

Even if there is no working tree, there can still be directories inside a repository. What revision should they have? I chose current:

[Edd Dumbill (edd-usefulinc)]

Just adding my request for a fix to be merged into the trunk, it makes it impossible to use an RSS reader to track project changes, as many bogus Changeset [current:] items appear.

[Edd Dumbill (edd-usefulinc)]

Toshio Kuratomi's patch unfortunately doesn't work against Trac 0.11 and the latest version of trac-bzr trunk, I get this backtrace:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/Trac-0.11b2-py2.5.egg/trac/timeline/web_ui.py", line 160, in process_request
    filters):
  File "/usr/lib/python2.5/site-packages/Trac-0.11b2-py2.5.egg/trac/versioncontrol/web_ui/changeset.py", line 787, in get_timeline_events
    key=collapse_changesets):
  File "/usr/lib/python2.5/site-packages/Trac-0.11b2-py2.5.egg/trac/versioncontrol/api.py", line 228, in get_changesets
    if chgset.date < start:
TypeError: can't compare datetime.datetime to float
2008-04-19 10:41:10,871 Trac[main] WARNING: 500 Trac Error (<p class="message">Repository checkins event provider (<tt>ChangesetModule</tt>) failed:<br/>TypeError: can't compare datetime.datetime to float</p><p>You may want to see the other kind of events from the <a href="/doap/timeline?wiki=on&amp;wiki=on&amp;ticket=on&amp;milestone=on">Timeline</a></p>)

[Václav Slavík (vslavik)]

> Toshio Kuratomi's patch unfortunately doesn't work against Trac 0.11 and the latest version of trac-bzr trunk, I get this backtrace:

Updated patch on http://bazaar.launchpad.net/~vslavik/trac-bzr/trac0.11 branch: http://bazaar.launchpad.net/~vslavik/trac-bzr/trac0.11/revision/vslavik%40fastmail.fm-20080522121100-vbidtl651kqcgtxe?start_revid=vslavik%40fastmail.fm-20080522125008-iqzylyarwalr8fcy

[Václav Slavík (vslavik)]

I think a better way to address the "current:" revision problem with timeline is not include it in the first place. I made this change in r44 of http://bazaar.launchpad.net/~vslavik/trac-bzr/trac0.11 and everything seems to work fine so far.

[Toshio Kuratomi (toshio)]

The changes mentioned in the previous comment have been merged into lp:trac-bzr here:

  http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/revision/44

I have built and started testing that for a new Fedora Package and it seems to work. I haven't thrown an RSS reader and some commits at it yet, though. If someone else would confirm the fix this bug could likely be marked closed.

[Grahack (christophegragnic)]

Hi, I am up to date with lp:trac-bzr but still see the phantom changeset.
My suggestion:
Would it be possible to override get_timeline_events in the ITimelineEventProvider interface?
It's currently implemented in trac/versioncontrol/web_ui/changeset.py.
Could we just remove the undesired event from here?

[Grahack (christophegragnic)]

Sorry, problem must be on my side.
Problem was with 0.11.2. I tested locally with 0.11.2.1 which had no phantom. Upgraded the first to 0.11.2.1 but the problem is still there.
Could it be the version of bzr (pb with 1.5 while bzr 1.3 is ok)?

[Pekka Jääskeläinen (pekka-jaaskelainen)]

This is still there, I tried with bzr 1.11 and trac 0.11.1 and there some strange [null:] changeset always at the top of the timeline after every commit.

[Pekka Jääskeläinen (pekka-jaaskelainen)]

What seems to be strangest that this [null:] changeset is displayed only for me. I asked 3 colleagues and for them there was no Changeset: [null:] :) Oh well... I tried upgrading to trac 0.11.2 and no help.

Attached is an image of the thing.

[Jelmer Vernooij (jelmer)]

It's not the trac/bzr versions that matter, but the trac-bzr (plugin) version. I can't reproduce this so marking it as incomplete.

[Pekka Jääskeläinen (pekka-jaaskelainen)]

lp:trac-bzr revno 54, just reinstalled it from there a couple of times to be sure.

Should I try some other branch?

[PresuntoRJ (fabio-tleitao)]

I have the same null change set here, but I also had to migrate my trac to ther system and I'have got a new sympthom...

Trac Error

Repository checkins event provider (ChangesetModule) failed:
NoSuchChangeset: No changeset null: in the repository

I never had the working tree on my servers

I have even tried the trac-bzr 0.2+bzr54-0devsuki2 , but with no success

[Martin von Gagern (gagern)]

I just added a get_changesets implementation to trac-bzr tunk. This should avoid issues like the ones described here. Please give it a try.