|
Size: 2635
Comment:
|
Size: 2646
Comment: minor wording
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| == hgweb links to ancestor's blame == Often when people use blame, they want to trace a file or block's history back through time. It is difficult to do this on hgweb (or via the CLI for that matter) today. Adding a link to hgweb that loaded the blame for the same line on the nearest ancestor changeset that modified that line/block would be a massive time saver. == Keyboard shortcuts on hgweb == Adding keyboard shortcuts to hgweb for navigating blame could be very useful. |
|
| Line 8: | Line 14: |
| Line 18: | Line 23: |
| == hgweb links to ancestor's blame == Often when people use blame, they want to trace a file or block's history back through time. It is difficult to do this on hgweb (or via the CLI for that matter) today. Adding a link to hgweb that loaded the blame for the same line on the nearest ancestor changeset that modified that line/block would be a massive time saver. == Keyboard shortcuts on hgweb == Adding keyboard shortcuts to hgweb for navigating blame could be very useful. |
|
| Line 25: | Line 24: |
| If hgweb exposed websockets or some other streaming protocol for receiving blame data, we could construct an advanced blame viewer that incrementally loaded blame information and allowed quick navigation between revisions. For example, the page could start by rendering the plain file content with no blame information. In the background, a websocket request starts receiving blame information for every revision of the file. As the blame information is received, the per-line/block blame information is updated and the DOM stores a copy of the history of blame. A horizontal slider could be used to rapidly switch between revisions. These wouldn't require round trips to the server because the DOM has already stored blame information on multiple revisions. |
If hgweb exposed websockets or some other streaming protocol for receiving blame data, we could construct an advanced blame viewer that incrementally loaded blame information and allowed quick navigation between revisions. For example, the page could start by rendering the plain file content with no blame information. In the background, a websocket request starts receiving blame information for every revision of the file. As the blame information is received, the per-line/block blame information is updated and the browser stores a copy of the history of blame. A horizontal slider could be used to rapidly switch between revisions. These wouldn't require round trips to the server because the browser has already stored/cached blame information on multiple revisions. |
This page documents potential improvements to blame/annotate functionality.
Separate blame algorithm from presentation code
Currently, the low-level annotate function lives in context.py. Formatting of things like line numbers also occurs inside the function. There needs to be a refactoring to separate concerns.
hgweb links to ancestor's blame
Often when people use blame, they want to trace a file or block's history back through time. It is difficult to do this on hgweb (or via the CLI for that matter) today. Adding a link to hgweb that loaded the blame for the same line on the nearest ancestor changeset that modified that line/block would be a massive time saver.
Keyboard shortcuts on hgweb
Adding keyboard shortcuts to hgweb for navigating blame could be very useful.
Calculate blame from tip to base
Currently, blame is calculated by starting at the base revision and applying deltas until you get to revision being blamed. It might be faster to calculate blame by starting at revision being blamed and apply reverse deltas until all lines have a revision attached.
Automatically skip revisions
It would be nice if you could easily configure blame to ignore certain changesets or types of changes. e.g. whitespace only changes, manually specified revset.
Preserve data for each revision
Currently, calling annotate() returns results for the requested revision and nothing else. Internally, annotate() builds up state for multiple revisions before returning the state of the requested revision. If we preserved this old state, we could do things like send it to consumers that are capable of storing every revision and quickly cycling between them.
See also the advanced HTML interface below for ideas on how this data could be used.
Advanced HTML interface
If hgweb exposed websockets or some other streaming protocol for receiving blame data, we could construct an advanced blame viewer that incrementally loaded blame information and allowed quick navigation between revisions. For example, the page could start by rendering the plain file content with no blame information. In the background, a websocket request starts receiving blame information for every revision of the file. As the blame information is received, the per-line/block blame information is updated and the browser stores a copy of the history of blame. A horizontal slider could be used to rapidly switch between revisions. These wouldn't require round trips to the server because the browser has already stored/cached blame information on multiple revisions.