Tag Archives: mercurial

How to use Mercurial Keyring extension with TortoiseHg

Uncategorized, , , , ,

With Mercurial, you need to enter your password every time you clone, push or pull from a private remote repository (like at BitBucket for example). The Mercurial Keyring extension eliminates the need to enter your password for every single operation. Using it with TortoiseHg to clone, push or pull is really easy.

  1. Enable the Mercurial Keyring extension. Right-click anywhere in Windows Explorer and choose TortoiseHg → Global Settings → Extensions. Enable mercurial_keyring.
  2. Close all open windows of TortoiseHg.
  3. The next time you clone or push or pull with a remote repository, TortoiseHg will prompt for your password. Enter it.
  4. After that one time, TortoiseHg will not ask your password again. Push and pull to your heart’s content :-)

Tried with: TortoiseHg 2.4.1 and Windows 7 Professional x64

About these ads

Mercurial configuration files on Linux

Uncategorized, ,

On Linux, there are three types of configuration files read by Mercurial: local (to a particular repository), per-user and per-system. When a configuration setting appears in more than one of these files, the local overrides per-user which overrides per-system.

The local configuration file is named hgrc and lies in the .hg subdirectory of the repository.

The per-user configuration file has to be named .hgrc and placed in $HOME directory.

The per-system configuration file has to be named hgrc and placed in the /etc/mercurial directory.

There are a few other per-system configuration options that are more complicated: .rc files in the installation directory or the /etc/mercurial directory.

More information about configuration file names and paths can be found using:

$ hg help config

Tried with: Mercurial 2.0.2

Show compact revision history in Mercurial

Uncategorized, ,

The command to view the revision history in Mercurial is hg log. This shows a lot of information: the revision number (local to the repository), the changeset ID, user, date and summary, each on a different line. This style of revision history occupies too many lines of the display.

A more compact revision history can be viewed by using:

hg log --style=compact

This shows the summary on one line and the rest of the information on a single line above it.

To view the revision history in the GNU changelog style use:

hg log --style=changelog

To apply one of these revision history styles by default on hg log, add this to your Mercurial configuration file:

[ui]
style = compact

If you have applied a different revision history style on hg log, but want to view it in default style use:

hg log --style=default

Tried with: Mercurial 2.3.2

Mercurial configuration files on Windows

Uncategorized, ,

On Windows, there are three types of configuration files read by Mercurial: local (to a particular repository), per-user and per-system. When a configuration setting appears in more than one of these files, the local overrides per-user which overrides per-system.

The local configuration file is named hgrc and is found in the .hg subdirectory of the repository.

The per-user configuration file can be named either .hgrc or Mercurial.ini. It can be placed either in %USERPROFILE% or %HOMEDRIVE%%HOMEPATH% directory.

The per-system configuration file has to be named Mercurial.ini. It can be in the installation directory of Mercurial.

There are a couple of other per-system configuration options that are more complicated: .rc files in the installation directory or using the registry.

More information about configuration file names and paths can be found using:

$ hg help config

Tried with: Mercurial 2.3.2

Comments in the hgrc file

Uncategorized, ,

The hgrc is the primary configuration file of a Mercurial repository. It may sometimes be useful to document some of its contents with comments.

The hgrc file follows the INI file format. In the INI file format, a line beginning with a semicolon (;) character is a comment line. So, this can be used in a hgrc file to write comments.

Some software that read INI files also allow the hash (#) character to begin a line of comments. Mercurial supports this too in the hgrc file as a comment line.

Tried with: Mercurial 2.2.2 on Windows 7 64-bit

Mercurial: Exporting a Revision Using Archive

Uncategorized, ,

Most of the work of transitioning from one version control system to another is figuring out the mapping from the jargon of the old one to the new. In Subversion, you could give someone a copy of a certain version using the export command. The copy thus created would be free of any repository information.

The corresponding operation in Mercurial is called archive. This creates an unversioned archive of a certain revision of the repository. Creating an archive of the current revision of your repository to give to a colleague named Ram is as easy as:

$ hg archive ../Copy-For-Ram

Another cool feature of the archive command is that it can create archives in compressed formats like zip. For example, to create a zip archive of the above:

$ hg archive Copy-For-Ram.zip

The hash of the revision being exported can be used in the name of the destination directory or file. For example:

$ hg archive Copy-For-Ram-%h.zip

The above command will create a file whose name might be Copy-For-Ram-72f497079285.zip, where 72f497079285 is the hash of the exported revision.

(Thanks to Rudi and Paul on StackOverflow for these tips.)

Tried with: Mercurial 1.9.2

Mercurial: Waiting for Lock

Uncategorized,

Problem

Mercurial repositories can sometimes be left in a locked state. A lock is created whenever a client is connected to a repository. But, this lock is not removed if the client got disconnected, say over the network. If any client now tries to change the repository (say push changes), Mercurial complains that it is waiting for the lock.

Here is an example:

P:\Foobar>hg push
pushing to Q:\FoobarRep
waiting for lock on repository Q:\FoobarRep held by 'Computer42:9999'

In this example, Mercurial is complaining that a lock is still being held by a client from the computer named Computer42 over port 9999.

Solution

Delete the lock file in the .hg\store directory of the repository. In the example above, delete the file Q:\FoobarRep\.hg\store\lock

Mercurial: Waiting for lock

Uncategorized,

In some rare cases, you get this error when pushing changes to a Mercurial repository:

$ hg push
pushing to D:\HgReps\Foobar
waiting for lock on repository D:\HgReps\Foobar held by ”
interrupted!

A few solutions to this problem:

  • Figure out the process holding a lock onto the repository and kill it.
  • If the above does not work, delete the file .hg/store/lock in the repository D:\HgReps\Foobar

Tried with: Mercurial 1.6 on Windows 7

Mercurial: Collaborating on a Windows Network Using Shares

Uncategorized, ,

You might feel the need to publish Mercurial repositories in a central location and collaborate using that. This is really useful when:

  • You are working from 2 or more workstations or laptops.
  • You are in a small team and there are 2 or more people working on the project.

Publishing a Mercurial repository in a central location enables different people or computers to push and pull from it. There are a few common ways to do this:

  • hg serve: Real easy and quick to setup with simple features.
  • SSH: Not as easy on Windows as on Linux. OpenSSH server is the most common option, but it comes with Cygwin and all its problems.
  • HTTP: Requires quite a lot of configuration on Windows.
  • SMB: If you are on a Windows network, your computers or team is small in number and your needs are simple, then using a Windows share is very compelling!

You can start publishing Mercurial repositories using Windows shares in just a few minutes:

  1. Designate one computer as the central repository server. Let us call it A. It can be the workstation of the one of the team members, it does not really matter. Other computers, B and C, should be in the same Windows network as A.
  2. Create a directory on A, say D:\HgReps and move all your current repositories to it. New repositories in the future should also be created here.
  3. Share the directory on A, so it becomes \\A\HgReps. Give only the team members who use A, B and C access to read and write to this share. You could also give read access to other users who you wish only pull from A. These access permissions should be very easy to configure if you are in a well set up Windows domain.
  4. Point all the current working directories on A, B and C to push and pull from \\A\HgReps. To do this, open the .hg/hgrc file in each working directory and edit it so it points to A. For a project named Foobar, the .hg/hgrc file looks like: 
    [paths]
default = \\A\HgReps\Foobar

All this setup is ridiculously easy to do for a small team and everything just works without much configuration. Another nice side-effect is that you can backup the D:\HgReps on computer A easily and grab all the team’s commits.