Editing Mercurial

[https://www.mercurial-scm.org Mercurial] (sometimes referred to as {{codeline|hg}}) is the source code management system used for Octave development.

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>

== Workflow reference ==
This section gives several frequently used Mercurial commands and sequences.

* Initial clone: <pre>hg clone https://hg.savannah.gnu.org/hgweb/octave/</pre>

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

* 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) ==

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

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:

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== 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 repository.

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

== Example Mercurial configuration ==

Place the following file in your home directory, e.g. {{Path|/home/username/.hgrc}}.



== Footnotes ==

<references/>

== External links ==

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