Editing Mercurial

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
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.
+
[[wikipedia:Mercurial]] (sometimes referred to as {{codeline|hg}}) is the version control tool used by Octave.
 +
This page contains some helpful commands to use when interacting with the GNU Octave mercurial repository.
  
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>
+
== Patches ==
 +
When you do not have push permissions to the repository (you cannot add your changes using mercurial itself) and you have a modification to the current GNU Octave code, you have to generate a patch (or changeset) so developers with permissions can include them in the code. The overview of the process is as follows
 +
# Change the code and test that your changes do work (write tests, that's the best!).
 +
# Create the changeset (instructions below).  
 +
# Post your patch in the [https://savannah.gnu.org/patch/?group=octave Patch tracker].
  
{{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.}}
+
=== Before starting ===
 +
The way patches are generated uses an [http://mercurial.selenic.com/wiki/MqExtension extension] of mercurial and therefore you need to prepare your .hgrc file to use it.
 +
If you do not have a .hgrc file, just create one in your home directory. In Windows, this is something like "C:\Documents and Settings\your_name\Mercurial.ini"
  
== Creating and submitting patches (changesets) ==
+
Add the following code to that file:
 
+
  [ui]
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.
+
  username = Your Real Name <some@email.com>
 
+
# 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>
+
[extensions]
# 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!}}
+
  hgext.mq =
# 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)
+
hgext.pager =
 
+
  color =
* scripts/help/help.m: Describe what you changed to display relevant topics
 
  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 {{file|bug42424.patch|<syntaxhighlight lang="diff"># 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
+
[pager]
-    [text, format] = get_help_text (name);
+
pager = LESS='FSRX' less
+    [text, format] = get_better_help_text (name);
+
attend = help, annotate, cat, diff, export, glog, log, qdiff, status, outgoing, incoming
 
   
 
   
    ## Take action depending on help text format
+
## Colours I like
    switch (lower (format))
+
[color]
 +
status.modified = magenta bold
 +
status.added = green bold
 +
status.removed = red bold
 +
status.deleted = cyan bold
 +
status.unknown = gray  bold
 +
status.ignored = gray bold
  
</syntaxhighlight>}}
+
The only part that is important is the extensions. The rest is to make hg behave in a fancy way (recommended).
# 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 ==
+
=== Creating changesets with hg ===
 +
==== Simple way ====
 +
* Update to the latest revision.
 +
<pre> hg up </pre>
 +
* Make your changes and save.
 +
* Commit your code following the [[commit message guidelines]].
 +
<pre> hg ci </pre>
 +
* Export the modifications.
 +
<pre> hg export -r tip -o mypatch.patch </pre>
 +
* Save the output to a file and upload it tot he patch tracker.
  
This section is meant to provide tips for [[Summer of Code]] students working on new Octave features.
+
==== Using the MQ extension ====
 +
In the repository you can start a patch by doing
 +
hg qnew mychangeset
  
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>.
+
You can further edit your files... if you do, you need your patch to know about these changes. To do that execute
 +
hg qrefresh
  
=== Using bookmarks ===
+
Once you think you have all the changes that make your patch complete you can export your patch
 +
hg qdiff > mychangeset.patch
  
[https://www.mercurial-scm.org/wiki/Bookmarks Bookmarks] are useful for identifying a series of commitsThey are a "lightweight" solution to [https://www.mercurial-scm.org/wiki/NamedBranches named branches], which are not automatically updated for exampleTo create a bookmark <code>my-gsoc</code> use
+
Now you can do (at least) two things
 +
* Apply your patch to your copy (it will differ form the repository and you will have to merge somehow...). To do it run
 +
  hg qfinish tip
 +
* Forget the changes and go back to the unpatched version of the code.
 +
hg qrefresh
 +
hg qpop
 +
  hg qfinish tip
  
<syntaxhighlight lang="bash">
+
The file mychangeset.patch contains your changes.
hg clone https://www.octave.org/hg/octave
 
hg bookmark my-gsoc
 
</syntaxhighlight>
 
  
To make the bookmark visible in the public repository use
 
  
<syntaxhighlight lang="bash">
+
== Mercurial Tips for SoC students ==
hg push --bookmark ssh://student@public.server.org/octave
 
</syntaxhighlight>
 
 
 
=== Staying up-to-date with the main repository ===
 
  
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:
+
This section is meant to provide tips for SOCIS or GSoC students working on new Octave features.
  
<syntaxhighlight lang="bash">
+
Students should publish their work as it progresses in a public repository
hg pull https://www.octave.org/hg/octave  # Get latest remote "tip"
+
merging regularly the main savannah repository to facilitate merging back their
hg update -r my-gsoc                      # Activate bookmark "my-gsoc"
+
code at the end of the project.  
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
 
</syntaxhighlight>
 
  
=== Preparing for code reviews ===
+
Here are some useful hg commands that can be used to do this.
  
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.
+
=== Getting started ===
 +
<!--[[File:Hg-student-start.png]]-->
 +
<ol>
 +
<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>
  
# 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:
+
=== Staying up-to-date with the main savannah repository ===
#* Each touched file should appear only once.
 
#* Do not mention backed-out commits.
 
# Prepare a singe patch (changeset) including all code that should be submitted for review <syntaxhighlight lang="bash">
 
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
 
</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.
 
  
== Example Mercurial configuration ==
+
<!-- After working for a while, the public repo should look like the following picture. -->
 +
As the students development proceeds,
 +
the savannah repository gets updated, too.
 +
To avoid having the two branches diverging too much, which can
 +
lead to conflicts when the final merge is done, students should
 +
keep their public repo up-to-date with the recent changes,
 +
the following commands can be used for this:<br/>
 +
<ol>
 +
<!--[[File:Hg-student-flow1.png]] <br/>-->
 +
<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>
  
Place the following file in your home directory, e.g. {{Path|/home/username/.hgrc}}.
+
=== 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
{{File|.hgrc|<syntaxhighlight lang="ini">
+
for review and possibly inclusion into the main development branch. To this end students should:
[ui]
+
<ol>
username = Your Name <your@email>
+
<li> prepare a full log of their changes, listing files that have been touched
 
+
and including a summary of the purpose of those changes. If students have been following
[extensions]
+
  the [[Commit message guidelines]] the following command will give a good starting point<br>
color =
+
<code> hg log --style=changelog --no-merges --user student-name </code><br>
histedit =
+
this message should be edited so that
pager =
+
  <ol  style="list-style-type: lower-roman;">
rebase =
+
<li> each touched file appears only once </li>
strip =
+
<li> changes that were backed out should not be mentioned <!--(like changeset "H" in the above example)--> </li>
 
+
</ol>
[pager]
+
The main  purpose of this log is to make it easy, not only for the main mentor, but also for other developers who
pager = LESS='FSRX' less
+
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]].
attend = help, annotate, cat, diff, export, glog, log, outgoing, incoming
+
<li> prepare a merge changeset including all the code that should be submitted for review
 
+
  <ol style="list-style-type: lower-roman;">
[diff]
+
  <li> pull from the main repository<br/>
showfunc = True
+
  <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/>
[color]
+
  <code>hg up -r @</code><br/>
mode = terminfo
+
  <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/>
## Custom colors
+
  <code>hg commit </code><br/>
color.gray = 244
+
  <code>hg export @ > mid-term-review.changeset </code><br/>
color.orange = 202
+
  the file mid-term-review.changeset can then be sent to the [[mailto:octave-maintainers@octave.org  mailing list]] or posted
color.lightyellow = 191
+
  to the [[http://savannah.gnu.org/patch/?group=octave  patch tracker]]</li>
color.darkorange = 220
+
  </ol> </li>
color.brightyellow = 226
+
</ol>
 
 
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
 
</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 ===
+
== Mercurial Tips for SoC mentors ==
  
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.
+
Will fill in this section after trying out the above procedure at least once with a student
 +
and actually pushing his changes to the main repo.
  
Strip and commit:
+
<!---
# Pull changes from the upstream repository.
+
<code>
# 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)".
+
hg pull http://student.repo.url
# Update to the new tip (maybe in incremental steps).
+
</code>
# 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:
+
<code>
# Pull changes from the upstream repository.
+
hg pull http://www.octave.org/hg/octave
# Before updating to the new tip, import the local changeset to mq by selecting "Modify History" -> "Import to MQ" in the right click menu.
+
</code>
# 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:
+
<code>
# Pull changes from the upstream repository.
+
hg up -r @
# Select the local changeset that you'd like to rebase.
+
</code>
# 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 ==
+
<code>
 +
hg merge student_bookmark
 +
</code>
  
<references/>
+
<code>
 +
hg log --style=changelog --user student
 +
</code>
 +
-->
  
== External links ==
+
==External links==
  
* https://hginit.com/ -- Mercurial tutorial
+
* [http://mercurial.selenic.com/ Official website]
* https://www.mercurial-scm.org/wiki/Tutorial -- Mercurial tutorial
 
* 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]]

Please note that all contributions to Octave may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Octave:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)