Timeslider: What's really broken

[marcelklehr]

Please verify these four tests on your instance:

tests

Make sure you're running the latest version on develop branch.
Create a new pad and make some changes (aim for a fixed number of revisions)
Please refresh the page after each test and wait a bit allowing the timeslider to load all necessary things.

1. Click anywhere on the slider bar -> associated content should be displayed.
2. Drag the slider handle around -> associated contents should be displayed as you drag the handle.
3. Step through all revisions manually using the back and forward buttons -> associated contents should be displayed.
4. Click on the replay button -> all changes should be replayed, starting at the beginning.

[marcelklehr]

Using firefox 17 all tests pass on a pad with 3 revisions

[marcelklehr]

Using firefox 17 all tests pass on a pad with 30 revisions

[marcelklehr]

Using firefox 17 tests 1, 2, 3 and 4 fail on a pad with 100 revisions.

[JohnMcLear]

So TLDR any pad w/ > 100 revisions does not show changes in timeslider?

[JohnMcLear]

FYI I have a pad with 7899 versions and the timeslider works okay, it's just a bit slow if I go back a long time in it's history. It's still a serious bug though, we need to get to the bottom of it even if it's just a case of showing a "loading" modal when we dont have enough data available to the client

[Wikinaut]

Some positive feedback:

The present version commit 5eb09f9 (Mon Jan 14 14:26:30 2013 -0800) appears to work much better:

• timeslider works in majority of cases, and
• I regard this version as a major improvement.
• It's not a final solution fo the timeslider issue/s

because quick timeslider pin moves can still lead to a server script crash, which just happened on my test installation with an old and bigger pad.

[JohnMcLear]

A PR to re-enable TS tests #1476

[JohnMcLear]

As far as I understand this, if you are on point 10000 and click on point 50 it creates a changeset from 10000 to 50. This is bad.

What we want is some way of doing a changeset from 0 to 50, 1000 to 1050 etc.. This would be a lot quicker and provide a much smoother process.

Ideally what we will do is provide the users offline Storage or so with cached copies every 1000 revs or so. We could serve this when the user is on the pad.

A very simple fix that would get us started is to provide content at Rev:[0-10] to the browser so when the play button is hit the content is available.

Overall though I think the way the timeslider is provided is kinda broken. We don't provide historical search or an ability to see changes based on contributions Vs Time.

Revisions are not necessarily humanly conceivable concepts compared to time. Also there has been various discussions about making the timeslider a "plugin", while I'm not a fan of that I think it's worth considering so we can maintain it as a completely separate entity.

[dmitryuv]

AFAIK it works differently. On load it starts pulling changesets from last to first revision using specified granularity (always equals to 1). For each changeset it creates forward (changeset as is) and backward (inversed changeset) version. If you want to go from head (rev50) to rev20 (i'll use smaller numbers for simplicity), it will apply backward changesets 49..20 to the head. Going forward, as you move slider back and forth it will apply forward or backward transform to the current state one by one. Timeslider stuck if you move slider too far where no changests are available yet, until they gets loaded (because loader works sequentially).

You don't need to have separate storage, changesets storage already have full text each 100 revisions. To move quicker on the timeline, you can load nearest base revision, then only small set of transformations to move from base to selected position.

[JohnMcLear]

RE Storage I mean on the client so the request doesn't need to be made to the server unless the data isn't available.

[JohnMcLear]

I think you are correct on behavior btw, @Pita might want to share some thoughts here.