Page MenuHomeSoftware Heritage

browse: Add new orderings for revisions history views
ClosedPublic

Authored by anlambert on Oct 31 2018, 6:09 PM.

Details

Summary

Previously in history views, revisions were ordered according to the
BFS traversal of the revisions DAG.

This commit adds three new ordering type modifying the history display:

  • Committer date ordering: revisions are displayed in reverse chronological order of their commit date
  • DFS: revisions are ordered according to the DFS traversal of the revisions DAG
  • DFS post: revisions are ordered according to the DFS post traversal of the revisions DAG

The four types of revisions ordering can be easily switched through the UI.

Closes T1026

Depends on D629

Diff Detail

Repository
rDWAPPS Web applications
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

vlorentz added a subscriber: vlorentz.
vlorentz added inline comments.
swh/web/algos/revisions_walker.py
343 ↗(On Diff #1930)

Shouldn't this case be handled outside the class; with the contructor raising a ValueError when it is given None as path?

This revision is now accepted and ready to land.Nov 5 2018, 12:03 PM
anlambert added inline comments.
swh/web/algos/revisions_walker.py
343 ↗(On Diff #1930)

Indeed, this seems better. I will also enforce that the rev_start parameter can not be None in the abstract base class.

I wonder whether the algorithms should be pushed down to swh.storage. Is there a salient reason for keeping them up in swh.web?

Originally, I wanted to add the revisions walkers implementation to swh-storage but this was not clear to me how to use the iterator protocol through the client/server ping pong with msgpack.
So I implemented it client-side for the moment. But moving these algorithms to storage should speed them up, any suggestion to do so is welcomed.

Thinking it back, using the same mechanism as for the directory iterator I implemented some time ago could work here,
see https://forge.softwareheritage.org/source/swh-storage/browse/master/swh/storage/algos/dir_iterators.py

In that case, an instance of storage would be provided as parameter of the revisions walker classes
and thus their code could be moved to the algos directory of swh-storage.

Thinking it back, using the same mechanism as for the directory iterator I implemented some time ago could work here,
see https://forge.softwareheritage.org/source/swh-storage/browse/master/swh/storage/algos/dir_iterators.py

In that case, an instance of storage would be provided as parameter of the revisions walker classes
and thus their code could be moved to the algos directory of swh-storage.

Yes, that's what I was thinking, at least as a first step.

Currently working on it. Moving the implementation from web to storage was not really difficult.

Now, I am trying to write some simple tests by generating a dummy history that will capture the
different revisions ordering.

I will open a diff to storage when this is done, then update this one and make it depend on the storage one.

Update: rebase, move revisions walker implementation and tests to swh-storage (D629)

anlambert edited the summary of this revision. (Show Details)

Update: Improve revisions history views design and add better tooltips

Update: Rebase, cleanup and polish

Build has FAILED

Because the diff depends on D629 so you cannot really build it ;)

This revision is now accepted and ready to land.Nov 9 2018, 11:33 AM

Oh and you'll need a bump on a new swh-storage version as well.

Thank for the swh-storage version bump, I totally forgot about it.

Incoming landing after a last rebase.

Update: rebase and bump required swh-storage version

Update: Reinstate committer date display in revision view.

That diff is now ready to land. I will do it next week once the
v0.0.109 tag of swh-storage is created and pushed.

Jenkins build is failing due to swh-storage v0.0.109 not uploaded on PyPI yet.

This revision was automatically updated to reflect the committed changes.