• 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

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>

See hg clone

(Note that there exists also a possibility for internal branches and merges.)

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.

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

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.

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

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/

• Checkout the export/import feature: http://mercurial.selenic.com/wiki/TutorialExport