Mercurial: Difference between revisions

From Octave
Jump to navigation Jump to search
No edit summary
No edit summary
Line 45: Line 45:
* Save the output to a file and upload it tot he patch tracker.
* Save the output to a file and upload it tot he patch tracker.


==== Using the extension ====
==== Using the MQ extension ====
In the repository you can start a patch by doing  
In the repository you can start a patch by doing  
  hg qnew mychangeset
  hg qnew mychangeset
Line 64: Line 64:


The file mychangeset.patch contains your changes.
The file mychangeset.patch contains your changes.
== 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
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><code> hg up -r student-bookmark-name </code> <br/>
<!--[[File:Hg-student-flow2.png]] <br/>-->
<code> hg merge @ </code> </li>
<li><code> hg commit -m "periodic merge of default branch into my branch" </code> </li>
<!--[[File:Hg-student-flow3.png]] <br/>-->
<li><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  style="list-style-type: lower-roman;">
<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>
<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]].


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

Revision as of 03:55, 16 August 2013

wikipedia:Mercurial (sometimes referred to as 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.

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.

Before starting

The way patches are generated uses an 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:

[extensions]
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).

Creating changesets with hg

Simple way

  • Update to the latest revision.
 hg up 
 hg ci 
  • Export the modifications.
 hg export -r tip -o mypatch.patch 
  • Save the output to a file and upload it tot he patch tracker.

Using the MQ extension

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.


Mercurial Tips for SoC students

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. hg up -r student-bookmark-name
    hg merge @
  3. hg commit -m "periodic merge of default branch into my branch"
  4. 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 (like changeset "H" in the above example)

    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.