Mercurial/Desired Features

Improve the hgweb viewer

Add HTML anchors to many elements

Provide named anchors for various elements so that users may post links to them in bug reports, etc.

• line numbers in "file" and "annotate" view Already done in hg 1.0
• files and hunks in "revision" view, e.g. link to a particular hunk of https://hg.mozilla.org/mozilla-centra...v/1b97a74034d1 (In Mercurial 1.0, each line number is a link.)

Allow marking lines of "file" and "annotate" view

In bonsai, you can use a magic &mark=line-line,line-line URL parameter to mark interesting lines, e.g.: https://bonsai.mozilla.org/cvsblame.c....2.2&mark=8-12

1. Reimplement the mark parameter in hg "file" and "annotate" view
2. Add marking UI so that users can create a marked-up URI without hand-editing the URI

Make annotate fast and useful

Missing features compared to bonsai blame for CVS are ability to load in seconds instead of minutes (for nsCSSFrameConstructor, say) and the ability to see checkin comments with linkified bug numbers by hovering a revision. A bonus would be only having a link at the start of a "chunk" for a revision; right now hgweb anno is about twice as many bytes as bonsai cvsblame, even though the latter includes all checkin comments for the file.  Most of those bytes are anchor href values.

Add basic searching

From the root view or revision view of the hg viewer, give the ability for users to type "cssframeconstructor" and find nsCSSFrameConstructor.h/cpp in the default revision (root view) or the current revision (revision view).

Add graphical history viewing

Add the ability to get a graphical changelog of a particular file, and perhaps of the entire repository, similar to the bonsai functionality.

Because complete history is so large, it may make sense for this to be a dynamically-expandable view, using SVG, instead of a generated image.

This is somewhat like a web version of hg glog or hg view.

Improvements to give better overview of changes

It's hard to get a good summary of what has happened without checking the detailed log of every commit. This is something bonsai manages pretty well. Here's a small list of some of the problems:

• Ideally the summary, or at the very least the shortlog or changelog, should also specify which files have been edited. This is how bonsai works.
• Differentiate (with colors for example, or another column?) the author of a changeset from its commit message, for readability.
• It would be nice to be able to see the diff of a changeset without going to a new page. For example, clicking "diff" could retrieve this data and show it inline AJAX-style?
• In the shortlog/changelog: "(0) -10000 -3000 -1000 -300 -100 -60 tip" -- these links are unintelligible and confusing. How about something simpler like next page, or page 1,2 - 100 instead?
• I find it unintuitive to know the difference between "summary", "shortlog" and "changelog". Even after trying all of them, they really seem to be the same view with very minor differences.

Show file-mode changes

Currently, if you change a file's mode (e.g. from executuable to non-executable), hg diff will output a reasonable and concise summary of the change -- something like:

diff --git a/path/to/file b/path/to/file
old mode 100755
new mode 100644

It'd be great if hgweb showed something like this, too. Right now, it shows no diffs, though it does still list the modified files (but with the wrong "diff" link next to each file -- this diff link shows you the last content change, rather than the file-mode change).

For example, changeset 8a99db3f8680 simply removed the executable bit for a lot of non-executable files, and hgweb doesn't have a good way of showing the change.

Feature: linear history according to a particular repository

Because mercurial history can get very branch-y, we would like the ability to navigate through history linearly as it appears in a particular repository:

Step 1: mozilla-central

Step 2: local user clones m-c and adds commits

Step 3: new revisions in m-c

Step 4: user merges

Step 5: user pushes

So, the linear history of mozilla-central (the mainline) should be recorded somehow as A -> B -> E -> F. However, we should not require this information to be known at commit-time. It should be recorded when a changeset is pushed to mozilla-central.

Doing this should not impose special requirements on users: they should not have to create a special named branch for their intermediate changes, nor should they have to follow special rules about which direction a particular merge happens.

Possible implementation may include some kind of named-branch, or a datastore recording in which direction merges should be followed.

This implementation should work for multiple ancestries: e.g. a user should be able to follow either mozilla-central or actionmonkey history if they wish.

Client-side requirements

Add the ability to diff an arbitrary revision against its last ancestor in mozilla-central. So after step 4, the user should be able to do something like:

hg diff -rF --ancestor=mozilla-central

Add the ability for annotate and log to follow the history of mozilla-central:

$ hg log --follow=mozilla-central
changeset: F
changeset: E
changeset: B
changeset: A

Server requirements

none in particular, though I presume this will involve a post-push hook

hgweb requirements

In the web interface, the shortlog, changelog, file revisions, and annotate views should show a specific repository's linear history by default, and only note branch histories when explicitly requested by the user.

For example, mozilla-central's shortlog should show the mozilla-central repo's linear history.

In the shortlog and changelog views, each merge changeset in the linear history should appear with extra information. For example, as of this writing actionmonkey repo's shortlog shows hundreds of changes that were actually checked into CVS, then imported to cvs-trunk-mirror, then merged to mozilla-central, then merged to actionmonkey. Instead, it should show:

at Wed Feb 20 08:16:46 2008 -0800	jorendorff	Merge from mozilla-central ←Merges 1 changeset by bhearsum. expand
at Wed Jan 30 14:31:55 2008 -0800	jorendorff	Merge from mozilla-central to actionmonkey branch. ←Merges 468 changesets by 160 different committers. expand
at Wed Jan 23 13:02:44 2008 -0600	jorendorff	Bug 392883 - ActionMonkey: remove gcThingFlags (r=igor)
at Fri Jan 18 17:18:30 2008 -0600	jorendorff	Remove some JSAutoTempValueRooters inadvertently introduced during the merge (they break the build).
at Fri Jan 18 16:15:16 2008 -0600	jorendorff	Merge from mozilla-central to actionmonkey branch. ←Merges 373 changesets by 97 different committers. expand
at Thu Jan 17 12:11:06 2008 -0600	jorendorff	Bug 392602 - ActionMonkey: implement a new heuristic for JS_MaybeGC (r=igor)
at Fri Jan 11 15:55:36 2008 -0600	jorendorff	Fixes to make actionmonkey compile without JS_THREADSAFE again. All tests pass. (Rearranging the order of JSGC's data members is to silence a GCC warning about initializer order.)
at Fri Jan 11 10:14:34 2008 -0600	jorendorff	Bug 404879 - ActionMonkey: Modify js/src to use new thread-safe MMgc APIs (r=brendan) - Changeset 4, make gcPendingContext per-GC instead of global.
...

This gives a much more accurate view of what's going on in a given repository than the current view, which treats all changesets as equals.

The expanded view should look like hg glog or hg view, illustrating the branch and merge points visually.

For bonus points, if a merge only merges one changeset, like the first change shown in the above example, expand it by default.