Mercurial: Difference between revisions

From Octave
Jump to navigation Jump to search
(→‎Creating and submitting patches (changesets): Replace mirror by link to main repository)
 
(48 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[https://www.mercurial-scm.org Mercurial] (sometimes referred to as {{codeline|hg}}) is the source code management system used for Octave development.
[https://www.mercurial-scm.org Mercurial] (sometimes referred to as {{codeline|hg}}) is the source code management system used for Octave development.


== Contributing to Octave ==
Everybody is free to '''run, copy, distribute, study, change and improve'''<ref>https://www.gnu.org/philosophy/free-sw.en.html</ref> Octave's source code, given in the main repository at https://www.octave.org/hg/octave.  Use Mercurial to get the latest version of Octave <pre>hg clone https://www.octave.org/hg/octave</pre>


The preferred method to contribute to Octave is with Mercurial changesets.
== Workflow reference ==
Other forms of contributions (e.g., simple diff patches) are
This section gives several frequently used Mercurial commands and sequences.
also acceptable, but they slow down the review process.


If you plan on contributing to Octave:
* Initial clone: <pre>hg clone https://hg.savannah.gnu.org/hgweb/octave/</pre>


* See other [[Contribution guidelines]]
You can then bootstrap, configure and make, make check, maybe make install.
* Always include commit messages in changesets. Please follow the Octave [[commit message guidelines]]
 
* Follow the style guides for both [[Octave style guide|Octave]] and [[C++ style guide|C++]] languages.
* To update on a regular basis, you can do <pre>hg pull -u</pre> or <pre>hg pull && hg up</pre>
 
* To make a ''local clone'', you can clone from your main Octave repository on your computer to another directory like this: <pre>hg clone octave myfeature</pre> which will clone the Octave directory into a new directory called "myfeature". You'll need to cd to the correct directory first. Then you can cd into the new directory and run bootstrap, configure, make. To prevent a fresh download of gnulib, you can specify the path to the first Octave directory's gnulib if you want.
 
It is best practice to make a new clone directory for each feature or bugfix you work on, which makes recovery from mistakes much easier.
 
* To work on the stable branch instead of the default branch, make a local clone called "stable", then cd to it and <pre>hg update stable</pre>
 
* To circulate work-in-progress bugfixes: first cd to the relevant local clone, then edit the relevant files, verify that it builds, then <pre>hg diff &gt;/tmp/my.wip.patch</pre> and then upload that file to the bug tracker discussion. You can also copy-paste it into a bug discussion using ''verbatim'' tags if the patch is small enough. Accept feedback from the bug discussion and iterate your patch.
 
* When you're ready to commit your fix, first pull and update your main Octave directory from Savannah, then pull and update your local clones. Then build again to make sure things haven't broken. Then <pre>hg commit</pre> and type a summary and context for your change. Exit the editor, saving when it prompts. Build again so your build gets the latest hg id. Type <pre>hg export &gt;/tmp/my.patch</pre> and upload that file into the bug discussion. Wait for a maintainer to apply it with your name, then if you do <pre>hg in</pre> in your main Octave directory it'll show up as an incoming change. Do a pull and up to get that, then do a pull and up in your individual clone directories to get it there.
 
* To merge changes from stable to default <pre>hg merge stable</pre>. It's best to run this only in local clones that are already on the default branch. That way, local clones on stable don't have to switch branches before merging.
 
* To push to a repository, if you have push rights to that repository, you can see what's going out with <pre>hg out</pre> and then if you're happy with it you can<pre>hg push</pre>.
 
==Tutorials==
Joel Spolsky's Mercurial tutorial: [https://hginit.github.io/01.html https://hginit.github.io/01.html]
 
{{Note|[https://tortoisehg.bitbucket.io/ TortoiseHg] is a GUI for Mercurial and it is especially recommended for users doing their first steps with source code management systems.  Linux, macOS, and MS Windows are supported.}}


== Creating and submitting patches (changesets) ==
== Creating and submitting patches (changesets) ==


Everybody is free to obtain, built, and modify Octave's source code, given in the main repository at https://www.octave.org/hg/octave.  If you want to share your modifications, for example to fix a nasty '''bug #42424''', you cannot just submit your changes to Octave's main repository.  You have to generate a patch (or changeset) so Octave developers with permissions can include them into Octave's source code.
If you want to share your modifications, for example to fix a nasty '''bug #42424''', you cannot just submit your changes to Octave's main repository.  You have to generate a '''patch (or changeset)''' so other Octave developers can include them into Octave's source code.


# Get the latest revision of Octave (or some Octave package) <pre>hg clone https://www.octave.org/hg/octave</pre> or when already cloned <pre>hg pull && hg update</pre>
# Get the latest version of Octave (or some Octave package) <pre>hg clone https://www.octave.org/hg/octave</pre> or when already cloned <pre>hg pull && hg update</pre>
# Make your changes (fix the bug) and save them.
# Make your changes (fix bug #42424) and save them. '''Make sure that your changes don't introduce new bugs!'''  Thus it is recommended to [[Building | build Octave]] and to [[Tests | run Octave's test suite]] before proceeding.<br>{{Warning|Please follow the [[Contribution guidelines]] for C/C++ or Octave code files!}}
# Commit your changes <pre>hg commit</pre> Mercurial will open your default editor and ask you for a commit message.  Please follow the [[commit message guidelines]], e.g. <syntaxhighlight lang="text">help.m: Display relevant topics first (bug #42424)
# Commit your changes <pre>hg commit</pre> Mercurial will open your default editor<ref>To set your default Mercurial editor, read https://www.mercurial-scm.org/wiki/editor .</ref> and ask you for a commit message.  Please follow the [[commit message guidelines]], e.g. <syntaxhighlight lang="text">help.m: Display relevant topics first (bug #42424)


* scripts/help/help.m: Describe what you changed to display relevant topics
* scripts/help/help.m: Describe what you changed to display relevant topics
   first.  The maximal line width is 80 characters.</syntaxhighlight>
   first.  The maximal line width is 80 characters.</syntaxhighlight>
# Export the changes <pre>hg export -r tip -o bug42424.patch</pre> The final patch for submission will look like this<syntaxhighlight lang="patch">
# Export the changes <pre>hg export -r tip -o bug42424.patch</pre> The final patch for submission will look like this {{file|bug42424.patch|<syntaxhighlight lang="diff"># HG changeset patch
</syntaxhighlight>
# User Awesome Hacker <awesome@hacker.com>
# Date 1591780091 -32400
#      Wed Jun 10 18:08:11 2020 +0100
# Node ID 68c698c4f2fd98bf2d48234bd1da99e91763114f
# Parent  f5c9bb5955e7c9fddef5c3c3f115201e11b43b79
 
help.m: Display relevant topics first (bug #42424)
 
* scripts/help/help.m: Describe what you changed to display relevant topics
  first.  The maximal line width is 80 characters.
 
diff -r f5c9bb5955e7 -r 68c698c4f2fd scripts/help/help.m
--- a/scripts/help/help.m Tue Jun 09 14:11:13 2020 -0700
+++ b/scripts/help/help.m Wed Jun 10 18:08:11 2020 +0900
@@ -99,7 +99,7 @@ function retval = help (name)
    endif
    ## Get help text
-    [text, format] = get_help_text (name);
+    [text, format] = get_better_help_text (name);
    ## Take action depending on help text format
    switch (lower (format))
 
</syntaxhighlight>}}
# Upload {{Path|bug42424.patch}} to the [https://savannah.gnu.org/bugs/?group=octave bug] or [https://savannah.gnu.org/patch/?group=octave patch] tracker. If your patch file is larger than the upload limit, you can compress it before uploading. Please use a free format!
# Upload {{Path|bug42424.patch}} to the [https://savannah.gnu.org/bugs/?group=octave bug] or [https://savannah.gnu.org/patch/?group=octave patch] tracker. If your patch file is larger than the upload limit, you can compress it before uploading. Please use a free format!


== Mercurial Tips for SoC students ==
== Mercurial Tips for SoC students ==


This section is meant to provide tips for SOCIS or GSoC students working on new Octave features.
This section is meant to provide tips for [[Summer of Code]] students working on new Octave features.
 
Students should publish their work as it progresses in a public repository. In this section we use for example <code>public.server.org/octave</code>.
 
=== Using bookmarks ===
 
[https://www.mercurial-scm.org/wiki/Bookmarks Bookmarks] are useful for identifying a series of commits.  They are a "lightweight" solution to [https://www.mercurial-scm.org/wiki/NamedBranches named branches], which are not automatically updated for example.  To create a bookmark <code>my-gsoc</code> use


Students should publish their work as it progresses in a public repository
<syntaxhighlight lang="bash">
merging regularly the main savannah repository to facilitate merging back their
hg clone https://www.octave.org/hg/octave
code at the end of the project.
hg bookmark my-gsoc
</syntaxhighlight>


Here are some useful hg commands that can be used to do this.
To make the bookmark visible in the public repository use


=== Getting started ===
<syntaxhighlight lang="bash">
<!--[[File:Hg-student-start.png]]-->
hg push --bookmark ssh://student@public.server.org/octave
<ol>
</syntaxhighlight>
<li> Clone the main Octave repository at savannah:<br>
<code> hg clone http://www.octave.org/hg/octave </code> </li>
<li> Create a new bookmark:<br>
<code> hg bookmark student-bookmark-name </code> </li>
<li> Make the bookmark visible in the public repo, assuming the public repo is at <code>public.server.org/octave</code><br>
<code> hg push --bookmark ssh://student@public.server.org/octave </code> </li>
</ol>


=== Staying up-to-date with the main savannah repository ===
=== Staying up-to-date with the main repository ===


<!-- After working for a while, the public repo should look like the following picture. -->
Octave development does not stand still while the students development proceeds.  Octave's main repository gets updated, too. The following commands can be used to get these updated to the students clone of the main repository:
As the students development proceeds,
 
the savannah repository gets updated, too.  
<syntaxhighlight lang="bash">
To avoid having the two branches diverging too much, which can
hg pull https://www.octave.org/hg/octave   # Get latest remote "tip"
lead to conflicts when the final merge is done, students should
hg update -r my-gsoc                      # Activate bookmark "my-gsoc"
keep their public repo up-to-date with the recent changes,
hg merge tip                              # Merge  "tip" into "my-gsoc"
the following commands can be used for this:<br/>
hg commit -m "maint: merge default to my-gsoc"
<ol>
hg push ssh://student@public.server.org/octave
<!--[[File:Hg-student-flow1.png]] <br/>-->
</syntaxhighlight>
<li> Download new changes from the main line of development <br/>
<code> hg pull http://www.octave.org/hg/octave </code> </li>
<li> Merge the main line of development into the feature branch <br/>
<code> hg up -r student-bookmark-name </code> <br/>
<!--[[File:Hg-student-flow2.png]] <br/>-->
<code> hg merge @ </code> </li>
<li> Apply the change and publish it <br/>
<code> hg commit -m "periodic merge of default branch into my branch" </code> <br/>
<!--[[File:Hg-student-flow3.png]] <br/>-->
<code> hg push ssh://student@public.server.org/octave </code></li>
</ol>


=== Preparing for code reviews ===
=== Preparing for code reviews ===
At the time of the mid-term or final review (or whenever the mentor requires it) students should prepare their code  
 
for review and possibly inclusion into the main development branch. To this end students should:
At the time of the mid-term or final review (or whenever the mentor requires it) students should prepare their code for review and possibly inclusion into the main repository.
<ol>
 
<li> prepare a full log of their changes, listing files that have been touched
# Create a full log of changes <pre>hg log --template=changelog --no-merges --user student-name</pre> If students have been following the [[Commit message guidelines]] the output is a good starting point for the commit message in the next step. Some manual post-processing might be necessary:
and including a summary of the purpose of those changes. If students have been following
#* Each touched file should appear only once.
the [[Commit message guidelines]] the following command will give a good starting point<br>
#* Do not mention backed-out commits.
<code> hg log --style=changelog --no-merges --user student-name </code><br>
# Prepare a singe patch (changeset) including all code that should be submitted for review <syntaxhighlight lang="bash">
this message should be edited so that
hg pull https://www.octave.org/hg/octave  # Get remote "tip" and "@"
  <ol  style="list-style-type: lower-roman;">
hg update -r @                             # Activate    bookmark "@"
<li> each touched file appears only once </li>
hg merge my-gsoc                          # Merge "my-gsoc" into "@"
<li> changes that were backed out should not be mentioned <!--(like changeset "H" in the above example)--> </li>
hg commit
</ol>
hg export -r tip -o mid-term-review.patch
The main  purpose of this log is to make it easy, not only for the main mentor, but also for other developers who
</syntaxhighlight> The file {{Path|mid-term-review.patch}} can uploaded to the [https://savannah.gnu.org/patch/?group=octave patch tracker]. <br/> Finally, there is a subtle difference between <code>"tip"</code>, which is a reference to the (local or remote) changeset added to the repository most recently and the bookmark <code>"@"</code> used by the Octave developers to point to the latest remote changeset.  Often both refer to the very same changeset and they can used interchangeably.
have not been closely following the progress of the project to quickly understand where to look at in the code to evaluate it, but it will also be used as the commit message for the merge changeset, so it should itself comply with the [[Commit message guidelines]].
<li> prepare a merge changeset including all the code that should be submitted for review
  <ol style="list-style-type: lower-roman;">
  <li> pull from the main repository<br/>
  <code>hg pull http://www.octave.org/hg/octave</code></li>
   <li> move to the top of the main line of development and merge in the feature branch<br/>
  <code>hg up -r @</code><br/>
  <code>hg merge student-bookmark-name </code><br/></li>
  <li> create a changeset, export it and send to the mentor for review, remember to use the log created above as a commit message<br/>
  <code>hg commit </code><br/>
  <code>hg export @ > mid-term-review.changeset </code><br/>
  the file mid-term-review.changeset can then be sent to the [mailto:octave-maintainers@octave.org mailing list] or posted
  to the [https://savannah.gnu.org/patch/?group=octave patch tracker]</li>
  </ol> </li>
</ol>


== Example Mercurial configuration ==
== Example Mercurial configuration ==
Line 105: Line 121:
Place the following file in your home directory, e.g. {{Path|/home/username/.hgrc}}.
Place the following file in your home directory, e.g. {{Path|/home/username/.hgrc}}.


{{File|.hgrc|<pre>
{{File|.hgrc|<syntaxhighlight lang="ini">
[ui]
[ui]
username = Your Name <your@email>
username = Your Name <your@email>
Line 140: Line 156:
status.ignored = gray bold
status.ignored = gray bold


## Colours for each label
## Colors for each label
log.branch = cyan
log.branch = cyan
log.summary = lightyellow
log.summary = lightyellow
Line 160: Line 176:
[alias]
[alias]
glog = log --graph
glog = log --graph
top = log --graph -l
top = log --graph -l
</pre>}}
</syntaxhighlight>}}
 
== Tips for working with TortoiseHg ==
 
TortoiseHg is a multi-platform graphical user interface for Mercurial repositories. It allows to perform many hg operations using the context menu and toolbar buttons. That might make it easier to get used to working with Mercurial.
 
=== Activate the "mq" extension ===
 
The "mq" extension allows to modify (local) changesets after they have been committed. It also allows to rebase changes to a new parent or to strip changes completely.
The "mq" extension does *not* allow to modify pushed changes.
 
To activate the "mq" extension in TortoiseSVN, open the settings, select "Extensions" on the global settings tab and activate the checkbox next to "mq".
 
The most useful feature of that extension is probably to update an existing changeset. For this, select "Modify History" -> "Import to MQ" in the right click menu of the respective changeset. After updating some local files or changing the commit message, hit the "QRefresh" button. Finish the patch by selecting "Modify History" -> "Finish Patch" from the right click menu of the respective changeset.
 
=== Rebase a change to a current tip ===
 
Sometimes a change in the upstream repository might make it necessary to rebase a changeset to a new parent. There are several ways to achieve this. The ways described here might not be the most elegant ones. Any editor is welcome to add onto this.
 
Strip and commit:
# Pull changes from the upstream repository.
# Before updating to the new tip, strip the local changes by selecting "Modify History" -> "Strip..." from the right click menu. In the dialog, select "Do not modify working copy during strip (-k/--keep)".
# Update to the new tip (maybe in incremental steps).
# Commit the local changes in a "fresh" changeset. This has the drawback that any commit message might be lost. But it often works even if other approaches fail.
 
Un-apply and re-apply:
# Pull changes from the upstream repository.
# Before updating to the new tip, import the local changeset to mq by selecting "Modify History" -> "Import to MQ" in the right click menu.
# You might want to refresh the changeset with local changes.
# Un-apply the patch by selecting "Modify History" -> "Unapply Patch" from the right click menu. If there are other, un-committed changes in the local repository, you might want to select "Tolerate non-conflicting local changes (--keep-changes)" in the "Modify History" -> "MQ Options" dialog from the right click menu beforehand.
# Update to the new tip.
# Select the previously unapplied patch on top of the revision graph and re-apply it by using the "Reapply Patch" option in the right click menu. This has the advantage that a commit message will be retained. But re-applying the patch might fail if there were changes in the upstream repository that made the patch incompatible.
 
Rebase:
# Pull changes from the upstream repository.
# Select the local changeset that you'd like to rebase.
# Hold down the Ctrl key and select the changeset that should be the new parent of the local changeset (probably the new tip).
# Right-click the changeset of the new parent and select "Rebase...".
# The default settings are often times fine. This process has the advantage that a commit message will be retained and it often times resolves conflicts automatically. But it doesn't work if there are any un-committed local changes.
 
== Footnotes ==
 
<references/>


== External links ==
== External links ==
Line 168: Line 226:
* https://www.mercurial-scm.org/wiki/Tutorial -- Mercurial tutorial
* https://www.mercurial-scm.org/wiki/Tutorial -- Mercurial tutorial
* https://www.mercurial-scm.org/wiki/QuickStart -- Mercurial quick start
* https://www.mercurial-scm.org/wiki/QuickStart -- Mercurial quick start
* https://tortoisehg.bitbucket.io/ -- TortoiseHg is a GUI for Mercurial (Linux, macOS, MS Windows)


[[Category:Development]]
[[Category:Development]]

Latest revision as of 17:15, 4 April 2024

Mercurial (sometimes referred to as hg) is the source code management system used for Octave development.

Everybody is free to run, copy, distribute, study, change and improve[1] Octave's source code, given in the main repository at https://www.octave.org/hg/octave. Use Mercurial to get the latest version of Octave

hg clone https://www.octave.org/hg/octave

Workflow reference[edit]

This section gives several frequently used Mercurial commands and sequences.

  • Initial clone:
    hg clone https://hg.savannah.gnu.org/hgweb/octave/

You can then bootstrap, configure and make, make check, maybe make install.

  • To update on a regular basis, you can do
    hg pull -u
    or
    hg pull && hg up
  • To make a local clone, you can clone from your main Octave repository on your computer to another directory like this:
    hg clone octave myfeature
    which will clone the Octave directory into a new directory called "myfeature". You'll need to cd to the correct directory first. Then you can cd into the new directory and run bootstrap, configure, make. To prevent a fresh download of gnulib, you can specify the path to the first Octave directory's gnulib if you want.

It is best practice to make a new clone directory for each feature or bugfix you work on, which makes recovery from mistakes much easier.

  • To work on the stable branch instead of the default branch, make a local clone called "stable", then cd to it and
    hg update stable
  • To circulate work-in-progress bugfixes: first cd to the relevant local clone, then edit the relevant files, verify that it builds, then
    hg diff >/tmp/my.wip.patch
    and then upload that file to the bug tracker discussion. You can also copy-paste it into a bug discussion using verbatim tags if the patch is small enough. Accept feedback from the bug discussion and iterate your patch.
  • When you're ready to commit your fix, first pull and update your main Octave directory from Savannah, then pull and update your local clones. Then build again to make sure things haven't broken. Then
    hg commit
    and type a summary and context for your change. Exit the editor, saving when it prompts. Build again so your build gets the latest hg id. Type
    hg export >/tmp/my.patch
    and upload that file into the bug discussion. Wait for a maintainer to apply it with your name, then if you do
    hg in
    in your main Octave directory it'll show up as an incoming change. Do a pull and up to get that, then do a pull and up in your individual clone directories to get it there.
  • To merge changes from stable to default
    hg merge stable
    . It's best to run this only in local clones that are already on the default branch. That way, local clones on stable don't have to switch branches before merging.
  • To push to a repository, if you have push rights to that repository, you can see what's going out with
    hg out
    and then if you're happy with it you can
    hg push
    .

Tutorials[edit]

Joel Spolsky's Mercurial tutorial: https://hginit.github.io/01.html

Info icon.svg
TortoiseHg is a GUI for Mercurial and it is especially recommended for users doing their first steps with source code management systems. Linux, macOS, and MS Windows are supported.

Creating and submitting patches (changesets)[edit]

If you want to share your modifications, for example to fix a nasty bug #42424, you cannot just submit your changes to Octave's main repository. You have to generate a patch (or changeset) so other Octave developers can include them into Octave's source code.

  1. Get the latest version of Octave (or some Octave package)
    hg clone https://www.octave.org/hg/octave
    or when already cloned
    hg pull && hg update
  2. Make your changes (fix bug #42424) and save them. Make sure that your changes don't introduce new bugs! Thus it is recommended to build Octave and to run Octave's test suite before proceeding.
    Warning icon.svg
    Please follow the Contribution guidelines for C/C++ or Octave code files!
  3. Commit your changes
    hg commit
    Mercurial will open your default editor[2] and ask you for a commit message. Please follow the commit message guidelines, e.g.
    help.m: Display relevant topics first (bug #42424)
    
    * scripts/help/help.m: Describe what you changed to display relevant topics
      first.  The maximal line width is 80 characters.
    
  4. Export the changes
    hg export -r tip -o bug42424.patch
    The final patch for submission will look like this
    File: bug42424.patch
    # HG changeset patch
    # User Awesome Hacker <awesome@hacker.com>
    # Date 1591780091 -32400
    #      Wed Jun 10 18:08:11 2020 +0100
    # Node ID 68c698c4f2fd98bf2d48234bd1da99e91763114f
    # Parent  f5c9bb5955e7c9fddef5c3c3f115201e11b43b79
    
    help.m: Display relevant topics first (bug #42424)
    
    * scripts/help/help.m: Describe what you changed to display relevant topics
      first.  The maximal line width is 80 characters.
    
    diff -r f5c9bb5955e7 -r 68c698c4f2fd scripts/help/help.m
    --- a/scripts/help/help.m	Tue Jun 09 14:11:13 2020 -0700
    +++ b/scripts/help/help.m	Wed Jun 10 18:08:11 2020 +0900
    @@ -99,7 +99,7 @@ function retval = help (name)
         endif
     
         ## Get help text
    -    [text, format] = get_help_text (name);
    +    [text, format] = get_better_help_text (name);
     
         ## Take action depending on help text format
         switch (lower (format))
    
  5. Upload bug42424.patch to the bug or patch tracker. If your patch file is larger than the upload limit, you can compress it before uploading. Please use a free format!

Mercurial Tips for SoC students[edit]

This section is meant to provide tips for Summer of Code students working on new Octave features.

Students should publish their work as it progresses in a public repository. In this section we use for example public.server.org/octave.

Using bookmarks[edit]

Bookmarks are useful for identifying a series of commits. They are a "lightweight" solution to named branches, which are not automatically updated for example. To create a bookmark my-gsoc use

hg clone https://www.octave.org/hg/octave
hg bookmark my-gsoc

To make the bookmark visible in the public repository use

hg push --bookmark ssh://student@public.server.org/octave

Staying up-to-date with the main repository[edit]

Octave development does not stand still while the students development proceeds. Octave's main repository gets updated, too. The following commands can be used to get these updated to the students clone of the main repository:

hg pull https://www.octave.org/hg/octave   # Get latest remote "tip"
hg update -r my-gsoc                       # Activate bookmark "my-gsoc"
hg merge tip                               # Merge  "tip" into "my-gsoc"
hg commit -m "maint: merge default to my-gsoc"
hg push ssh://student@public.server.org/octave

Preparing for code reviews[edit]

At the time of the mid-term or final review (or whenever the mentor requires it) students should prepare their code for review and possibly inclusion into the main repository.

  1. Create a full log of changes
    hg log --template=changelog --no-merges --user student-name
    If students have been following the Commit message guidelines the output is a good starting point for the commit message in the next step. Some manual post-processing might be necessary:
    • Each touched file should appear only once.
    • Do not mention backed-out commits.
  2. Prepare a singe patch (changeset) including all code that should be submitted for review
    hg pull https://www.octave.org/hg/octave   # Get remote "tip" and "@"
    hg update -r @                             # Activate    bookmark "@"
    hg merge my-gsoc                           # Merge "my-gsoc" into "@"
    hg commit
    hg export -r tip -o mid-term-review.patch
    
    The file mid-term-review.patch can uploaded to the patch tracker.
    Finally, there is a subtle difference between "tip", which is a reference to the (local or remote) changeset added to the repository most recently and the bookmark "@" used by the Octave developers to point to the latest remote changeset. Often both refer to the very same changeset and they can used interchangeably.

Example Mercurial configuration[edit]

Place the following file in your home directory, e.g. /home/username/.hgrc.

File: .hgrc
[ui]
username = Your Name <your@email>

[extensions]
color =
histedit =
pager =
rebase =
strip =

[pager]
pager = LESS='FSRX' less
attend = help, annotate, cat, diff, export, glog, log, outgoing, incoming

[diff]
showfunc = True

[color]
mode = terminfo

## Custom colors
color.gray = 244
color.orange = 202
color.lightyellow = 191
color.darkorange = 220
color.brightyellow = 226

status.modified = magenta bold
status.added = green bold
status.removed = red bold
status.deleted = cyan bold
status.unknown = gray bold
status.ignored = gray bold

## Colors for each label
log.branch = cyan
log.summary = lightyellow
log.description = lightyellow
log.bookmark = green
log.tag = darkorange
log.graph = blue

## Colors for each phase
changeset.secret = blue bold
changeset.draft  = red bold
changeset.public = orange

desc.here = bold blue_background

[bookmarks]
track.current = True

[alias]
glog = log --graph
top  = log --graph -l

Tips for working with TortoiseHg[edit]

TortoiseHg is a multi-platform graphical user interface for Mercurial repositories. It allows to perform many hg operations using the context menu and toolbar buttons. That might make it easier to get used to working with Mercurial.

Activate the "mq" extension[edit]

The "mq" extension allows to modify (local) changesets after they have been committed. It also allows to rebase changes to a new parent or to strip changes completely. The "mq" extension does *not* allow to modify pushed changes.

To activate the "mq" extension in TortoiseSVN, open the settings, select "Extensions" on the global settings tab and activate the checkbox next to "mq".

The most useful feature of that extension is probably to update an existing changeset. For this, select "Modify History" -> "Import to MQ" in the right click menu of the respective changeset. After updating some local files or changing the commit message, hit the "QRefresh" button. Finish the patch by selecting "Modify History" -> "Finish Patch" from the right click menu of the respective changeset.

Rebase a change to a current tip[edit]

Sometimes a change in the upstream repository might make it necessary to rebase a changeset to a new parent. There are several ways to achieve this. The ways described here might not be the most elegant ones. Any editor is welcome to add onto this.

Strip and commit:

  1. Pull changes from the upstream repository.
  2. Before updating to the new tip, strip the local changes by selecting "Modify History" -> "Strip..." from the right click menu. In the dialog, select "Do not modify working copy during strip (-k/--keep)".
  3. Update to the new tip (maybe in incremental steps).
  4. Commit the local changes in a "fresh" changeset. This has the drawback that any commit message might be lost. But it often works even if other approaches fail.

Un-apply and re-apply:

  1. Pull changes from the upstream repository.
  2. Before updating to the new tip, import the local changeset to mq by selecting "Modify History" -> "Import to MQ" in the right click menu.
  3. You might want to refresh the changeset with local changes.
  4. Un-apply the patch by selecting "Modify History" -> "Unapply Patch" from the right click menu. If there are other, un-committed changes in the local repository, you might want to select "Tolerate non-conflicting local changes (--keep-changes)" in the "Modify History" -> "MQ Options" dialog from the right click menu beforehand.
  5. Update to the new tip.
  6. Select the previously unapplied patch on top of the revision graph and re-apply it by using the "Reapply Patch" option in the right click menu. This has the advantage that a commit message will be retained. But re-applying the patch might fail if there were changes in the upstream repository that made the patch incompatible.

Rebase:

  1. Pull changes from the upstream repository.
  2. Select the local changeset that you'd like to rebase.
  3. Hold down the Ctrl key and select the changeset that should be the new parent of the local changeset (probably the new tip).
  4. Right-click the changeset of the new parent and select "Rebase...".
  5. The default settings are often times fine. This process has the advantage that a commit message will be retained and it often times resolves conflicts automatically. But it doesn't work if there are any un-committed local changes.

Footnotes[edit]

External links[edit]