Mercurial Tips

• Subversion Tips — Git Tips — CVS Tips
• hg lists basic commands, hg help lists all commands and hg help <command> shows the help for <command>
• Infos are scattered over wiki/UnderstandingMercurial, the wiki/Tutorial, the Workflow Guide and the Hgbook
• Analysis of Git and Mercurial by Google
• Best place to start is Hg Init, a Mercurial tutorial
• Intro and comparison to Git

(As an alternative if the package of the distro is outdated)

1. Remove the original package from the system (removepkg mercurial…)
2. Download and unpack the newest source tarball
3. Cd into unpacked dir and type make to get help
4. Type make install
5. Create the file /etc/profile.d/mercurial.sh with this content:

   export PYTHONPATH="/usr/local/lib/python2.5/site-package"

Step 4 installs the following content to usr/local/:

lib/python2.5/site-packages/hgext/
lib/python2.5/site-packages/mercurial/
lib/python2.5/site-packages/mercurial-1.8.4-py2.5.egg-info
bin/hg
share/man/man1/hg.1        # not with 1.8 ?
share/man/man5/hgrc.5      # not with 1.8 ?
share/man/man5/hgignore.5  # not with 1.8 ?

See also

Configuration of mercurial is done in $HOME/.hgrc. See http://www.selenic.com/mercurial/hgrc.5.html

; ~/.hgrc
 
[extensions]
hgext.graphlog =
hgext.extdiff =
 
[extdiff]
cmd.kdiff = kompare
 
[paths]
someShortcut = ssh://someUrl/somePath/someProject

Add this to the file $HOME/.hgrc:

[extensions]
hgext.graphlog =

Usage: hg glog [OPTIONS] - More

Sources: TipsAndTricks Extdiff extension HGBook

Download and install colordiff from www.slackbuilds.org. Then add the following to $HOME/.hgrc:

[extensions]
hgext.extdiff =
 
[extdiff]
cmd.cdiff = colordiff
opts.cdiff = -uprN

Usage: hg cdiff [...] [| less -R]

Add the following to $HOME/.hgrc:

[extensions]
hgext.extdiff =
 
[extdiff]
cmd.kdiff = kompare

Edit ~/.hgrc (More):

[ui]
username = New Username <new@address>

Bookmarks for often accessed remote repositories can be set in .hgrc. Example:

alias

http://www.selenic.com/mercurial/hg.1.html#urls

Just edit .hg/hgrc in your local repo. More

Cd into the root directory of your project and type hg init. This merely creates the subdir .hg which is the repository. The current dir becomes the working dir of the project.

Add all files to the project by hg add and hg commit

Source

Log-like commands can be formatted with froatting strings, wich ar called templates. A style is simply a precanned template. Command to list all installed styles:

hg log --template list

Command to incluce phase info into the log:

hg glog --template phases
hg glog -T phases

This is a no-brainer See ConvertExtension. Note that the conversion worked witout the cvsps tool mentioned there (On Slack 12.2 with Mercurial 1.4.1)

hg convert <pathToCheckedOutCvsModule>

Remommendation: Use internal branches, i.e. hg branch and add a bookmark to each branch. Don't use hg clone or named branches for branching.

See alo http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Pulling from another repository usually creates a 2nd head (= 2nd branch) in your repo.

This section describes how to create e.g. client-specific variants of the same main project eg. for special needs of customers.

Use wiki/RebaseExtension and fix rest of this section.

Using the example of css-skins:

Project structure:

.
|-- .hgignore
|-- index.html
|-- skin.css -> skins_user/franz.css
|-- skins_dist
|   |-- default.css
|   |-- helmut.css
|   `-- otto.css
`-- skins_user
    `-- franz.css

.hgignore:

syntax: glob

skin.css
skins_user

• Distributed skins go to skins_dist which are part of the repo
• User-supplied skins go to user_dist which is hgignored (exclueded from the repo)
• Optionally create a sub-repo in the subdir to track local changes of the variant.
• Make a (hgignored !) symlink skin.css to the currently used skin and refer to this skin only via the symlink from the other code
• Have a fallback mechanism to use skins_dist/default.css if no symlink is available
• Can also use another config file instead of a symlink
• This concept can be muliplied for several independent variant topics (skins, conf-templates, …)

Advantages: Every distributed skin is accessible in every repo. Everything can pushed and pulled in every direction.
Disadvantage: Symlink must be created after cloning a repo

• Clone the „trunk“-repo for each variant
• Change whatever you want in the variant repo
• Edit generic code only in the trunk
• Pull changes of the trunk into the variants (and merge), but never the other way around!

Suitable for projects which are not under your control, i.e. where you just use the code and don't contribute back.

hg revert <file1> [<file2>]

Restores the files in the working directory to the state when they had been last commited. Much more options are posssible, see hg help revert Hgbook Wiki

Do hg rollback (and afterwards hg revert)

Use hg backout REV. The old commit is not deleted from history, but reverted as new commit

hg strip (can also be used to remove an older head)

Or:

Use clone -r <revnumber> <old> <new> to create a repo which contains only the changesets until <revnumber>. Than throw away the original repo and use the cloned repo.

hg histedit e.g. for merging serveral changesets into one. See Wiki

Wrong histeds may be reverted by hg unbundle .hg/strip-backup/<backupfile>. This works for wrong hg rebases as well.

Copy changes from other branches onto the current branch: See hg/help/graft

Source: MqTutorial

hg init --mq             # Start / -c for version control / qinit is deprecated
hg qnew -m 'message' name_of_patch    # Create new patch
hg qrefresh              # Update the patch with the new changes
hg qapplied              # Show currently pushed patches
hg qfinish name_of_patch # Make the patch a permanent commit
 
# Pull changes from upstream:
hg qpop -a               # remove all patches from repo
hg pull -u
hg qpush -a              # apply all patches to repo
 
# Push changes to upstream:???
hg qpop -a               # remove all patches from repo
hg push
hg qpush -a              # apply all patches to repo

Basically there is Pull-only versus shared-push collaboration. See also wiki/WorkingPractices

Uncomment or add the following line to /etc/httpd/httpd.conf:

LoadModule cgi_module lib/httpd/modules/mod_cgi.so

Source

Create file /etc/mercurial/webrc¹⁾:

[collections]
/home/share/hgroot = /home/share/hgroot
 
[web]
allow_archive = gz, zip, bz2
encoding = UTF-8

Copy hgweb.cgi from root dir of the mercurial source²⁾ tarball to /var/www/cgi-bin/hgweb and correct the path to the webrc config file:

7c7
< config = "/path/to/repo/or/config"
---
> config = "/etc/mercurial/webrc"

Clone some repositories into /home/share/hgroot and point browser to http://localhost/cgi-bin/hgweb/

With the HgGit extension you can push/pull to/from a remote (or local) Git repo while doing all the work in a local Hg repo. A nice way to get around Git commands

See http://hg-git.github.io/ for more info.

HgGit needs dulwich. Both is available on www.slackbuilds.org

Local repo (L) is hg, remote repo (R) is git.
We want to push/pull to/from branch master on R

Verify:

1. L needs a (manually created) bookmark master which tells HgGit to push to / pull from which branch on R. Checkout if that bookmark must point to tip in order to get pushed all commits! Checkout if the bookmark must be active on L!
2. The tag default/master is autmatically created and moved on L on every push to / pull from R
3. In order to push from L to R, R must not be on the branch to which to L wants to push (see push)

See https://www.mercurial-scm.org/wiki/HgGit

To push an existing Mercurial repository to Github:

1. Import your public SSH key to Github
2. Create an empty repo, e.g. foo on Github
3. Cd into your local Hg repo and do

   hg bookmark -r default master # make a bookmark of master for default, so a ref gets created
   hg push git+ssh://git@github.com/becki/foo.git