Mercurial/Desired Features

  • Revision slug: Mercurial//Desired_Features
  • Revision title: Mercurial/Desired Features
  • Revision id: 137681
  • Created:
  • Creator: Dholbert
  • Is current revision? No
  • Comment /* Show file-mode changes */

Revision Content

Improvements to the Mercurial Client

hg rebase

(This is being worked on as part of the Summer of Code 2008.)

To keep history clean and avoid users having to merge in "simple" cases, implement an <tt>hg rebase</tt> command with similar semantics to <tt>git rebase</tt>. At a minimum, it should be able to do a three-way transplant of one head onto another from a common branch point:

Image:Rebase1.png

<tt>hg rebase E --onto= C</tt>

Image:Rebase2.png

If a conflict is found during merging, the normal 3-way merge tool is used to resolve the conflict. The user may halt operation to manually resolve conflicts and continue the process with <tt>hg rebase --continue</tt>.

After the merge is complete, new clean commits are created without any merge history:

Image:Rebase3.png

And the old commits and merges are stripped:

Image:Rebase4.png

Improve error messages

Throughout the client application, error messages should suggest the action to take to resolve the error, and link to web documentation for more details. In particular:

  • if <tt>hg push</tt> would cause multiple heads, suggest that the user rebase or merge
  • if <tt>hg qpush</tt> fails because the patch doesn't apply, suggest the steps necessary to rebase a queue (hg qsave/qpush -m)

additional rebase features

As with git-rebase, the user should have the option of reordering their local commits (in the example above, rebase so that the final sequence is E-Dmerged-Cmerged

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.

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.: http://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

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 <tt>hg glog</tt> or <tt>hg view</tt>.

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

Image:step1.png

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

Image:Step2.png

Step 3: new revisions in m-c

Image:Step3.png

Step 4: user merges

Image:Step4.png

Step 5: user pushes

Image:Step5.png

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 <tt>annotate</tt> and <tt>log</tt> 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 <tt>cvs-trunk-mirror</tt>, then merged to <tt>mozilla-central</tt>, then merged to <tt>actionmonkey</tt>. 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 <tt>hg glog</tt> or <tt>hg view</tt>, 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.

Revision Source

<h3 name="Improvements_to_the_Mercurial_Client"> Improvements to the Mercurial Client </h3>
<h4 name="hg_rebase"> hg rebase </h4>
<p>(This is being worked on as part of the <a class="external" href="http://www.selenic.com/mercurial/wiki/index.cgi/RebaseProject">Summer of Code 2008</a>.)
</p><p>To keep history clean and avoid users having to merge in "simple" cases, implement an <tt>hg rebase</tt> command with similar semantics to <tt>git rebase</tt>. At a minimum, it should be able to do a three-way transplant of one head onto another from a common branch point:
</p><p><img alt="Image:Rebase1.png" fileid="328" src="File:en/Media_Gallery/Rebase1.png">
</p><p><tt>hg rebase E --onto= C</tt>
</p><p><img alt="Image:Rebase2.png" fileid="330" src="File:en/Media_Gallery/Rebase2.png">
</p><p>If a conflict is found during merging, the normal 3-way merge tool is used to resolve the conflict. The user may halt operation to manually resolve conflicts and continue the process with <tt>hg rebase --continue</tt>.
</p><p>After the merge is complete, new clean commits are created without any merge history:
</p><p><img alt="Image:Rebase3.png" fileid="332" src="File:en/Media_Gallery/Rebase3.png">
</p><p>And the old commits and merges are stripped:
</p><p><img alt="Image:Rebase4.png" fileid="334" src="File:en/Media_Gallery/Rebase4.png">
</p>
<h4 name="Improve_error_messages"> Improve error messages </h4>
<p>Throughout the client application, error messages should suggest the action to take to resolve the error, and link to web documentation for more details. In particular:
</p>
<ul><li> if <tt>hg push</tt> would cause multiple heads, suggest that the user rebase or merge
</li><li> if <tt>hg qpush</tt> fails because the patch doesn't apply, suggest the steps necessary to rebase a queue (hg qsave/qpush -m)
</li></ul>
<h4 name="additional_rebase_features"> additional rebase features </h4>
<p>As with git-rebase, the user should have the option of reordering their local commits (in the example above, rebase so that the final sequence is E-Dmerged-Cmerged
</p>
<h3 name="Improve_the_hgweb_viewer"> Improve the hgweb viewer </h3>
<h4 name="Add_HTML_anchors_to_many_elements"> Add HTML anchors to many elements </h4>
<p>Provide named anchors for various elements so that users may post links to them in bug reports, etc.
</p>
<ul><li> <strike>line numbers in "file" and "annotate" view</strike> Already done in hg 1.0
</li><li> <strike>files and hunks in "revision" view</strike>, e.g. link to a particular hunk of <a class=" external" href="http://hg.mozilla.org/mozilla-central/?rev/1b97a74034d1" rel="freelink">http://hg.mozilla.org/mozilla-centra...v/1b97a74034d1</a> (In Mercurial 1.0, each line number is a link.)
</li></ul>
<h4 name="Allow_marking_lines_of_.22file.22_and_.22annotate.22_view"> Allow marking lines of "file" and "annotate" view </h4>
<p>In bonsai, you can use a magic &amp;mark=line-line,line-line URL parameter to mark interesting lines, e.g.:
<a class=" external" href="http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/tools/tinderbox-configs/firefox/win32/mozconfig&amp;rev=1.1.2.2&amp;mark=8-12" rel="freelink">http://bonsai.mozilla.org/cvsblame.c....2.2&amp;mark=8-12</a>
</p>
<ol><li> Reimplement the mark parameter in hg "file" and "annotate" view
</li><li> Add marking UI so that users can create a marked-up URI without hand-editing the URI
</li></ol>
<h4 name="Add_basic_searching"> Add basic searching </h4>
<p>From the <a class="external" href="http://hg.mozilla.org/mozilla-central/">root view</a> or <a class="external" href="http://hg.mozilla.org/mozilla-central/?rev/1b97a74034d1">revision view</a> 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).
</p>
<h4 name="Add_graphical_history_viewing"> Add graphical history viewing </h4>
<p>Add the ability to get a graphical changelog of a particular file, and perhaps of the entire repository, similar to the <a class="external" href="http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/tools/tinderbox-configs/firefox/win32/mozconfig">bonsai functionality</a>.
</p><p>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.
</p><p>This is somewhat like a web version of <tt>hg glog</tt> or <tt>hg view</tt>.
</p>
<h4 name="Improvements_to_give_better_overview_of_changes"> Improvements to give better overview of changes </h4>
<p>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:
</p>
<ul><li> 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.
</li><li> Differentiate (with colors for example, or another column?) the author of a changeset from its commit message, for readability.
</li><li> 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?
</li><li> 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?
</li><li> 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.
</li></ul>
<h4 name="Show_file-mode_changes"> Show file-mode changes </h4>
<p>Currently, if you change a file's mode (e.g. from executuable to non-executable), <code>hg diff</code> will output a reasonable and concise summary of the change -- something like:
</p>
<pre class="eval">diff --git a/path/to/file b/path/to/file
old mode 100755
new mode 100644
</pre>
<p>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 <i>content</i> change, rather than the file-mode change).
</p><p>For example, <a class="external" href="http://hg.mozilla.org/mozilla-central/index.cgi/rev/8a99db3f8680">changeset 8a99db3f8680</a> simply removed the executable bit for a lot of non-executable files, and hgweb doesn't have a good way of showing the change.
</p>
<h3 name="Feature:_linear_history_according_to_a_particular_repository"> Feature: linear history according to a particular repository </h3>
<p>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:
</p><p>Step 1: mozilla-central
</p><p><img alt="Image:step1.png" fileid="865" src="File:en/Media_Gallery/Step1.png">
</p><p>Step 2: local user clones m-c and adds commits
</p><p><img alt="Image:Step2.png" fileid="374" src="File:en/Media_Gallery/Step2.png">
</p><p>Step 3: new revisions in m-c
</p><p><img alt="Image:Step3.png" fileid="375" src="File:en/Media_Gallery/Step3.png">
</p><p>Step 4: user merges
</p><p><img alt="Image:Step4.png" fileid="376" src="File:en/Media_Gallery/Step4.png">
</p><p>Step 5: user pushes
</p><p><img alt="Image:Step5.png" fileid="377" src="File:en/Media_Gallery/Step5.png">
</p><p>So, the linear history of mozilla-central (the mainline) should be recorded somehow as A -&gt; B -&gt; E -&gt; F. However, we should not require this information to be known at <i>commit</i>-time. It should be recorded when a changeset is <i>pushed to mozilla-central</i>.
</p><p>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.
</p><p>Possible implementation may include some kind of named-branch, or a datastore recording in which direction merges should be followed.
</p><p>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.
</p>
<h4 name="Client-side_requirements"> Client-side requirements </h4>
<p>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:
</p>
<pre class="eval">hg diff -rF --ancestor=mozilla-central
</pre>
<p>Add the ability for <tt>annotate</tt> and <tt>log</tt> to follow the history of mozilla-central:
</p>
<pre class="eval">$ hg log --follow=mozilla-central
changeset: F
changeset: E
changeset: B
changeset: A
</pre>
<h4 name="Server_requirements"> Server requirements </h4>
<p>none in particular, though I presume this will involve a post-push hook
</p>
<h4 name="hgweb_requirements"> hgweb requirements </h4>
<p>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.
</p><p>For example, mozilla-central's shortlog should show the mozilla-central repo's linear history.
</p><p>In the shortlog and changelog views, each merge changeset in the linear history should appear with extra information. For example, as of this writing <a class="external" href="http://hg.mozilla.org/actionmonkey/?shortlog/10929">actionmonkey repo's shortlog</a> shows hundreds of changes that were actually checked into CVS, then imported to <tt>cvs-trunk-mirror</tt>, then merged to <tt>mozilla-central</tt>, then merged to <tt>actionmonkey</tt>. Instead, it should show:
</p>
<blockquote><table border="1" class="fullwidth-table">
<tbody><tr>
<td>at Wed Feb 20 08:16:46 2008 -0800</td>
<td><i>jorendorff</i></td>
<td><b>Merge from mozilla-central</b>
<p><i>←Merges 1 changeset by bhearsum. <u>expand</u></i>
</p>
</td>
</tr>
<tr>
<td>at Wed Jan 30 14:31:55 2008 -0800</td>
<td><i>jorendorff</i></td>
<td><b>Merge from mozilla-central to actionmonkey branch.</b>
<p><i>←Merges 468 changesets by 160 different committers. <u>expand</u></i>
</p>
</td>
</tr>
<tr>
<td>at Wed Jan 23 13:02:44 2008 -0600</td>
<td><i>jorendorff</i></td>
<td><b>Bug 392883 - ActionMonkey: remove gcThingFlags (r=igor)</b></td>
</tr>
<tr>
<td>at Fri Jan 18 17:18:30 2008 -0600</td>
<td><i>jorendorff</i></td>
<td><b>Remove some JSAutoTempValueRooters inadvertently introduced during the merge (they break the build).</b></td>
</tr>
<tr>
<td>at Fri Jan 18 16:15:16 2008 -0600</td>
<td><i>jorendorff</i></td>
<td><b>Merge from mozilla-central to actionmonkey branch.</b>
<p><i>←Merges 373 changesets by 97 different committers. <u>expand</u></i>
</p>
</td>
</tr>
<tr>
<td>at Thu Jan 17 12:11:06 2008 -0600</td>
<td><i>jorendorff</i></td>
<td><b>Bug 392602 - ActionMonkey: implement a new heuristic for JS_MaybeGC (r=igor)</b></td>
</tr>
<tr>
<td>at Fri Jan 11 15:55:36 2008 -0600</td>
<td><i>jorendorff</i></td>
<td><b>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.)</b></td>
</tr>
<tr>
<td>at Fri Jan 11 10:14:34 2008 -0600</td>
<td><i>jorendorff</i></td>
<td><b>Bug 404879 - ActionMonkey: Modify js/src to use new thread-safe MMgc APIs (r=brendan) - Changeset 4, make gcPendingContext per-GC instead of global.</b></td>
</tr>
<tr>
<td>...</td>
<td>
</td><td>
</td></tr>
</tbody></table></blockquote>
<p>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.
</p><p>The expanded view should look like <tt>hg glog</tt> or <tt>hg view</tt>, illustrating the branch and merge points visually.
</p><p>For bonus points, if a merge only merges one changeset, like the first change shown in the above example, expand it by default.
</p>
Revert to this revision