Mercurial: Difference between revisions

From Octave
Jump to navigation Jump to search
No edit summary
(→‎Mercurial configuration: Add missing color "gray". Minor changes of spelling and whitespace.)
(38 intermediate revisions by 10 users not shown)
Line 1: Line 1:
[[wikipedia:Mercurial]] (sometimes referred to as {{codeline|hg}}) is the version control tool used by Octave.
[[wikipedia:Mercurial|Mercurial]] (sometimes referred to as {{codeline|hg}})
This page contains some helpful commands to use when interacting with the GNU Octave mercurial repository.
is the source code management system currently used to develop
Octave.
 
== Introduction to Mercurial ==
 
An introduction to Mercurial is completely outside the scope of this document.
There are plenty of available documentation on the topic.  Some recommendations
are:
 
* [http://hginit.com/ Hg Init]
* [https://www.mercurial-scm.org/wiki/Tutorial Mercurial tutorial]
* [https://www.mercurial-scm.org/wiki/QuickStart Mercurial quick start]
 
== Contributing to Octave ==
 
The preferred method to contribute to Octave is with Mercurial changesets.
Other forms of contributions (e.g., simple diff patches) are
also acceptable, but they slow down the review process.
 
If you plan on contributing to Octave:
 
* See other [[Contribution guidelines]]
* 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.
 
== Getting the development sources ==
 
To clone the Octave repository:
 
hg clone http://www.octave.org/hg/octave octave
 
Octave packages like image, signal, control, etc. are not parts of Octave
itself, they belong to the Octave Forge.  Each package has its own
repository, a list of which can be found
[http://sourceforge.net/p/octave/_list/hg?source=navbar here].
You can clone them in a similar way, for example, to clone the signal package
 
hg clone http://hg.code.sf.net/p/octave/signal octave-signal
 
== Mercurial configuration ==
 
You can use the following to start your hgrc
 
{{File||<pre>
[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
 
## Colours 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
</pre>}}
 
== Submitting patches ==


== 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
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!).
# Change the code and test that your changes do work (write tests, that's the best!).
Line 8: Line 108:
# Post your patch in the [https://savannah.gnu.org/patch/?group=octave Patch tracker].
# Post your patch in the [https://savannah.gnu.org/patch/?group=octave Patch tracker].


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


Add the following code to that file:
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 on attaching
a changeset file.


[extensions]
=== Pull request ===
hgext.mq =
hgext.pager =
color =
[pager]
pager = LESS='FSRX' less
attend = help, annotate, cat, diff, export, glog, log, qdiff, status, outgoing, incoming
## Colours I like
[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


The only part that is important is the extensions. The rest is to make hg behave in a fancy way (recommended).
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 with hg ===
 
=== Creating changesets files with hg ===
==== Simple way ====
==== Simple way ====
* Update to the latest revision.  
* Update to the latest revision.  
<pre> hg up </pre>
<pre> hg up </pre>
* Make your changes and save.  
* Make your changes and save them.  
* Commit your code following the [[commit message guidelines]].  
* Commit your code. Mercurial will ask you for a commit message, which should follow the [[commit message guidelines]].
<pre> hg ci </pre>
<pre> hg ci </pre>
* Export the modifications.  
* 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>
<pre> hg export -r tip -o mypatch.patch </pre>
* Save the output to a file and upload it tot he patch tracker.
* 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!


==== Using the MQ extension ====
== Mercurial Tips for SoC students ==
In the repository you can start a patch by doing
hg qnew mychangeset
 
You can further edit your files... if you do, you need your patch to know about these changes. To do that execute
hg qrefresh
 
Once you think you have all the changes that make your patch complete you can export your patch
hg qdiff > mychangeset.patch
 
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
 
The file mychangeset.patch contains your changes.


This section is meant to provide tips for SOCIS or GSoC students working on new Octave features.


== Mercurial Tips for SoC students ==
<!--This page is addressed to SOCIS or GSoC applicants contributing to Octave.-->
Students should publish their work as it progresses in a public repository  
Students should publish their work as it progresses in a public repository  
merging regularly the main savannah repository to facilitate merging back their  
merging regularly the main savannah repository to facilitate merging back their  
code at the end of the project.  
code at the end of the project.  
Here are some useful hg commands that can be used to do this.
Here are some useful hg commands that can be used to do this.


Line 98: Line 167:
<li> Download new changes from the main line of development <br/>
<li> Download new changes from the main line of development <br/>
<code> hg pull http://www.octave.org/hg/octave </code> </li>
<code> hg pull http://www.octave.org/hg/octave </code> </li>
<li><code> hg up -r student-bookmark-name </code> <br/>
<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/>-->
<!--[[File:Hg-student-flow2.png]] <br/>-->
<code> hg merge @ </code> </li>
<code> hg merge @ </code> </li>
<li><code> hg commit -m "periodic merge of default branch into my branch" </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/>-->
<!--[[File:Hg-student-flow3.png]] <br/>-->
<li><code> hg push ssh://student@public.server.org/octave </code></li>
<code> hg push ssh://student@public.server.org/octave </code></li>
</ol>
</ol>


Line 109: Line 180:
At the time of the mid-term or final review (or whenever the mentor requires it) students should prepare their code  
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:
for review and possibly inclusion into the main development branch. To this end students should:
<ol style="list-style-type: lower-roman;">
<ol>
<li> prepare a full log of their changes, listing files that have been touched  
<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  
  and including a summary of the purpose of those changes. If students have been following  
Line 115: Line 186:
  <code> hg log --style=changelog --no-merges --user student-name </code><br>
  <code> hg log --style=changelog --no-merges --user student-name </code><br>
  this message should be edited so that  
  this message should be edited so that  
  <ol>
  <ol   style="list-style-type: lower-roman;">
  <li> each touched file appears only once </li>
  <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>
  <li> changes that were backed out should not be mentioned <!--(like changeset "H" in the above example)--> </li>
  </ol>
  </ol>
The main  purpose of this log is to make it easy, not only for the main mentor, but also for other developers who
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]].
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 ==


== Mercurial Tips for SoC students ==
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>
hg merge student_bookmark
</code>
 
<code>
hg log --style=changelog --user student
</code>
-->
 
==External links==
 
* [https://www.mercurial-scm.org/ Official website]


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

Revision as of 19:05, 9 April 2018

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

Introduction to Mercurial

An introduction to Mercurial is completely outside the scope of this document. There are plenty of available documentation on the topic. Some recommendations are:

Contributing to Octave

The preferred method to contribute to Octave is with Mercurial changesets. Other forms of contributions (e.g., simple diff patches) are also acceptable, but they slow down the review process.

If you plan on contributing to Octave:

Getting the development sources

To clone the Octave repository:

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

Octave packages like image, signal, control, etc. are not parts of Octave itself, they belong to the Octave Forge. Each package has its own repository, a list of which can be found here. You can clone them in a similar way, for example, to clone the signal package

hg clone http://hg.code.sf.net/p/octave/signal octave-signal

Mercurial configuration

You can use the following to start your hgrc

File:
[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

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

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

  1. Change the code and test that your changes do work (write tests, that's the best!).
  2. Create the changeset (instructions below).
  3. Post your patch in the Patch tracker.


Patch submissions is done via the bug or patch trackers. Either way, you can submit via two different methods: pull requests on 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 bitbucket


Creating changesets files with hg

Simple way

  • Update to the latest revision.
 hg up 
  • Make your changes and save them.
  • Commit your code. Mercurial will ask you for a commit message, which should follow the commit message guidelines.
 hg ci 
  • 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.
 hg export -r tip -o mypatch.patch 
  • 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

  1. Clone the main Octave repository at savannah:
    hg clone http://www.octave.org/hg/octave
  2. Create a new bookmark:
    hg bookmark student-bookmark-name
  3. Make the bookmark visible in the public repo, assuming the public repo is at public.server.org/octave
    hg push --bookmark ssh://student@public.server.org/octave

Staying up-to-date with the main savannah repository

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:

  1. Download new changes from the main line of development
    hg pull http://www.octave.org/hg/octave
  2. Merge the main line of development into the feature branch
    hg up -r student-bookmark-name
    hg merge @
  3. Apply the change and publish it
    hg commit -m "periodic merge of default branch into my branch"
    hg push ssh://student@public.server.org/octave

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:

  1. 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
    hg log --style=changelog --no-merges --user student-name
    this message should be edited so that
    1. each touched file appears only once
    2. changes that were backed out should not be mentioned

    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.

  2. prepare a merge changeset including all the code that should be submitted for review
    1. pull from the main repository
      hg pull http://www.octave.org/hg/octave
    2. move to the top of the main line of development and merge in the feature branch
      hg up -r @
      hg merge student-bookmark-name
    3. create a changeset, export it and send to the mentor for review, remember to use the log created above as a commit message
      hg commit
      hg export @ > mid-term-review.changeset
      the file mid-term-review.changeset can then be sent to the mailing list or posted to the patch tracker

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.

External links