Difference between revisions of "Mercurial"

From Octave
Jump to navigation Jump to search
m (→‎Submitting patches: spelling error)
 
(36 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[wikipedia:Mercurial|Mercurial]] (sometimes referred to as {{codeline|hg}})
+
[https://www.mercurial-scm.org Mercurial] (sometimes referred to as {{codeline|hg}}) is the source code management system used for Octave development.
is the source code management system currently used to develop
 
Octave.
 
  
== Introduction to Mercurial ==
+
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>
  
An introduction to Mercurial is completely outside the scope of this document.
+
{{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.}}
There are plenty of available documentation on the topic. Some recommendations
 
are:
 
  
* [http://hginit.com/ Hg Init]
+
== Creating and submitting patches (changesets) ==
* [https://www.mercurial-scm.org/wiki/Tutorial Mercurial tutorial]
 
* [https://www.mercurial-scm.org/wiki/QuickStart Mercurial quick start]
 
  
== Contributing to 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 other Octave developers can include them into Octave's source code.
  
The preferred method to contribute to Octave is with Mercurial changesets.
+
# 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>
Other forms of contributions (e.g., simple diff patches) are
+
# 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!}}
also acceptable, but they slow down the review process.
+
# 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)
  
If you plan on contributing to Octave:
+
* 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)
  
* See other [[Contribution guidelines]]
+
* scripts/help/help.m: Describe what you changed to display relevant topics
* Always include commit messages in changesetsPlease follow the Octave [[commit message guidelines]]
+
  firstThe maximal line width is 80 characters.
* Follow the style guides for both [[Octave style guide|Octave]] and [[C++ style guide|C++]] languages.
 
  
== Getting the development sources ==
+
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))
  
To clone the Octave repository:
+
</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!
  
  hg clone http://www.octave.org/hg/octave octave
+
== Mercurial Tips for SoC students ==
 +
 
 +
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
 +
 
 +
<syntaxhighlight lang="bash">
 +
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">
 +
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:
  
Octave packages like image, signal, control, etc. are not parts of Octave
+
<syntaxhighlight lang="bash">
itself, they belong to the Octave Forge. Each package has its own
+
hg pull https://www.octave.org/hg/octave  # Get latest remote "tip"
repository, a list of which can be found
+
hg update -r my-gsoc                      # Activate bookmark "my-gsoc"
[http://sourceforge.net/p/octave/_list/hg?source=navbar here].
+
hg merge tip                              # Merge "tip" into "my-gsoc"
You can clone them in a similar way, for example, to clone the signal package
+
hg commit -m "maint: merge default to my-gsoc"
 +
hg push ssh://student@public.server.org/octave
 +
</syntaxhighlight>
  
hg clone http://hg.code.sf.net/p/octave/signal octave-signal
+
=== Preparing for code reviews ===
  
== Mercurial configuration ==
+
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.
  
You can use the following to start your hgrc
+
# 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:
 +
#* 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.
  
{{File||<pre>
+
== Example Mercurial configuration ==
 +
 
 +
Place the following file in your home directory, e.g. {{Path|/home/username/.hgrc}}.
 +
 
 +
{{File|.hgrc|<syntaxhighlight lang="ini">
 
[ui]
 
[ui]
 
username = Your Name <your@email>
 
username = Your Name <your@email>
Line 78: Line 129:
 
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 99: Line 150:
 
glog = log --graph
 
glog = log --graph
 
top = log --graph -l
 
top = log --graph -l
</pre>}}
+
</syntaxhighlight>}}
 
 
== Submitting 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].
 
 
 
 
 
Patch submissions is done via the [https://savannah.gnu.org/bugs/?group=octave bug]
 
or [https://savannah.gnu.org/patch/?group=octave patch] trackers.  Either
 
way, you can submit via two different methods: pull requests or attaching
 
a changeset file.
 
 
 
=== Pull request ===
 
 
 
This is the cleaner way.  You push your clone to public site, and ask on the
 
bug tracker to pull a specific changeset from it.  It makes special sense if
 
you plan to send more patches in the future but requires to host the clone
 
somewhere.  Free mercurial repositories are available on [https://bitbucket.org/ bitbucket]
 
 
 
 
 
=== Creating changesets files with hg ===
 
==== Simple way ====
 
* Update to the latest revision.
 
<pre> hg up </pre>
 
* Make your changes and save them.
 
* Commit your code. Mercurial will ask you for a commit message, which should follow the [[commit message guidelines]].
 
<pre> hg ci </pre>
 
* Export the modifications. This creates a file (in the case of the example below, it is called mypatch.patch) that contains a description of the changes that you've made. Someone else can then apply the patch and end up with a repository that looks the same as yours.
 
<pre> hg export -r tip -o mypatch.patch </pre>
 
* Save the output to a file and upload it to the 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 ==
 
 
 
This section is meant to provide tips for SOCIS or GSoC students working on new Octave features.
 
 
 
Students should publish their work as it progresses in a public repository
 
merging regularly the main savannah repository to facilitate merging back their
 
code at the end of the project.
 
 
 
Here are some useful hg commands that can be used to do this.
 
 
 
=== 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>
 
 
 
=== Staying up-to-date with the main savannah repository ===
 
 
 
<!-- 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>
 
 
 
=== 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:
 
<ol>
 
<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
 
the [[Commit message guidelines]] the following command will give a good starting point<br>
 
<code> hg log --style=changelog --no-merges --user student-name </code><br>
 
this message should be edited so that
 
<ol  style="list-style-type: lower-roman;">
 
<li> each touched file appears only once </li>
 
<li> changes that were backed out should not be mentioned <!--(like changeset "H" in the above example)--> </li>
 
</ol>
 
The main  purpose of this log is to make it easy, not only for the main mentor, but also for other developers who
 
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>
 
 
 
== Mercurial Tips for SoC mentors ==
 
 
 
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.
 
<!---
 
<code>
 
hg pull http://student.repo.url
 
</code>
 
 
 
<code>
 
hg pull http://www.octave.org/hg/octave
 
</code>
 
 
 
<code>
 
hg up -r @
 
</code>
 
  
<code>
+
== Footnotes ==
hg merge student_bookmark
 
</code>
 
  
<code>
+
<references/>
hg log --style=changelog --user student
 
</code>
 
-->
 
  
==External links==
+
== External links ==
  
* [https://www.mercurial-scm.org/ Official website]
+
* https://hginit.com/ -- Mercurial tutorial
 +
* 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]]

Latest revision as of 22:13, 10 June 2020

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
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

Footnotes[edit]

External links[edit]