1-click AWS Deployment 1-click Azure Deployment
Overview
TortoiseHg is a set of graphical tools and a shell extension for the Mercurial distributed revision control system.
- On Windows:
- TortoiseHg consists of the Workbench graphical application, a shell extension which provides overlay icons and context menus in your file explorer, and a command line program named
thg.exewhich can launch the TortoiseHg tools. Binary packages of TortoiseHg for Windows come with Mercurial and a merge tool and are thus completely ready for use “Out of the Box”. - On Linux,
- TortoiseHg consists of a command line thg script and a Nautilus extension which provides overlays and context menus in your file explorer. You must have Mercurial installed separately in order to run TortoiseHg on Linux. TortoiseHg binary packages list Mercurial as a dependency, so it is usually installed for you automatically.
TortoiseHg is primarily written in Python and PyQt (the Windows shell extension being the notable exception). The thg script and TortoiseHg dialogs can be used on any platform that supports PyQt, including Mac OS X.
Installing TortoiseHg:
On Windows
TortoiseHg comes with an easy to use MSI installer. You can always find the most up to date release on our website. Simply double click on the installer file and follow its instructions.
After a first time install, a re-login is usually required to start the icon overlays.
During upgrades, the installer will ask to close or restart any applications that have loaded the TortoiseHg shell extension. If you allow those applications to be closed, the upgrade will not require a reboot or logout. If other users are logged in, or if there are applications which cannot be shutdown, a reboot will be required to complete the install.
If you have a legacy version of TortoiseHg installed, the installer will require that you to remove it. The uninstall can be initiated from the control panel or the start menu.
Warning
Legacy uninstallers (<=0.9.3) have a tendency to delete your user Mercurial.ini file, so backup your file before uninstalling the older TortoiseHg versions. This is not a problem with the newer MSI packages.
Legacy TortoiseHg installers (prior to version 1.0) were built with InnoSetup. They installed a TortoiseOverlay package as a separate application, so you always saw both TortoiseHg and TortoiseOverlay as two applications in the Add/Remove Programs control panel program. (On x64 platforms, there were two TortoiseOverlays, one for x86 processes and one of x64 processes).
The new MSI installers for TortoiseHg include the TortoiseOverlay packages as “merge modules” so they do not appear as separate applications anymore. It should be safe to uninstall the older TortoiseOverlay applications from Add/Remove Programs after you uninstalled the legacy (<=0.9.3) TortoiseHg installer, unless you have other Tortoise products that still use the separate TortoiseOverlay MSI approach (TortoiseCVS or TortoiseBZR).
TortoiseOverlay is a shim package that allows multiple Tortoise style shell extension clients to share overlay slots. This is necessary because even modern Windows platforms only support a limited number of overlay slots (11-14). TortoiseOverlay packages are created by the TortoiseSVN developers.
To be completely safe, there are two approaches you can take:
- Just leave the old TortoiseOverlay packages installed. They do not harm anything.
- Uninstall all the old TortoiseOverlay packages, then re-install all of your Tortoise products until they are all functional.
Finally, if you have problems with the shell extension even after re-logging in, we recommend you re-run the installer and select the Repair option. There were problems with a few versions of TortoiseOverlay that cause upgrades to subtly fail until the Repair process is run.
Language settings
The TortoiseHg user interface has been translated into many languages. Language packs are not required since all available languages are installed by default. You can select your preferred UI Language in the global settings tool.
The Windows shell extension context menus get their translations from the Windows registry. Translations for many locales were installed under C:\Program Files\TortoiseHg\i18n\cmenu. Select the locale you would like to use, double-click on it, and confirm all requests.
On Linux and Mac
The most recent Linux packages can be found on our download page.
For Mac OS X, no packages are available but you can run thg and all the dialogs via the source install method. For details, see Mac OS X.
If you install TortoiseHg from source, you need to add our contrib/mergetools.rc file to your HGRC path in some way. One approach is to %include it from your ~/.hgrc file.
The following philosophical changes were made between TortoiseHg 1.0 and TortoiseHg 2.0.
Workbench
We wanted a single ‘TortoiseHg’ application which can access nearly all TortoiseHg (and Mercurial) functionality and that could be launched by a desktop or start menu shortcut. So we developed the Workbench application.
The Workbench can support multiple repositories open at a time via “Repo Tabs” across the top of the main window.
Each repository tab supports multiple “Task Tabs” beneath its graph splitter. These task tabs are switchable via icons on the side of the Workbench or via application menus. Available task tabs include a changeset browser, a commit tool, a history search widget, and a sync widget.
Also available are two dockable widgets – a Repository Registry which lists all known repositories on your local machine and an Output Log Window which displays running command lines and their output and can also function as a minimal shell.
Showing Mercurial command lines
In an effort to educate users on Mercurial’s command interface, nearly all commands are executed in the log window, displaying the full command line and Mercurial’s output (progress indication is provided by progress bars inside the Workbench status bar). The few tools that do not use a command log window will generally display the command line they execute.
Resolve tool, deliberate merges
TortoiseHg 2.0 introduces a resolve dialog for resolving conflicted file merges. It shows the users all the files that require resolution and those files that have been resolved, allowing merges to be verified.
As supported by Mercurial’s resolve command, individual file merges may be restarted as many times as necessary to get the merge correctly completed.
By default, TortoiseHg will use the resolve dialog to resolve all conflicts, including trivial conflicts. It instructs Mercurial to never merge files automatically, deferring their resolution until the resolve dialog can be launched. This is true for merges, update commands that require content merges, rebases, and backouts.
Shelve Improved
TortoiseHg 2.0 includes a new shelve tool which is capable of moving changes between your working directory, a shelf file, or an unapplied MQ patch.
Revision Sets
We have replaced the filter bar of the Repository Explorer with a revision set bar in the Workbench. Revision sets were introduced in Mercurial 1.6 and have been integrated with an increasing number of commands in each subsequent release. They are a powerful query language for finding and specifying revisions in your repository.
The Workbench also includes a revision set editor which both teaches the user the available keywords and their arguments, and offers brace matching, auto-completions, and other editing amenities.
In TortoiseHg 2.0, incoming and outgoing changesets are visualized as revision sets. In previous versions they were represented by graph annotations.
Technology
Qt and PyQt
TortoiseHg 2.0 has been a near rewrite of all of the tools and dialogs taking advantage of Digia’s excellent Qt UI framework and Riverbank Computing’s fine PyQt Python bindings.
QScintilla2
TortoiseHg uses the QScintilla2 editing component extensively to:
- display file contents and diffs with syntax highlighting
- display annotations with syntax highlighting
- edit commit messages with auto-completion of filenames and source symbols
- edit revision set strings with brace matching and auto-completion
One can configure the QScintilla2 tab stop parameter using the settings tool, while white space visibility and wrap are controlled by context menus.
Polling of repository state and config
The Workbench and other applications like the commit tool will poll repositories on your local machine to detect changes made to either the repository or their configuration files, and automatically update running applications as necessary. Nearly all configuration changes are effective immediately, with the notable exception of enabling or disabling Mercurial extensions. Changes to extension configuration generally require application restarts before they take effect.
Immediate bug report dialogs
Prior to TortoiseHg 2.0, bug reports were written to stderr as they occured and stderr was captured and scanned at exit to report those errors to the user. While we gained many valuable bug reports via this mechanism, there was rarely any context on what operations caused these bugs.
In TortoiseHg 2.0, we have created a generic exception handler that catches all Python exceptions that are otherwise unhandled by application code. This allows us to display exception tracebacks almost immediately after they occur (after a short timeout to collect consecutive exceptions together). The hope is that future bug reports will contain better reproduction instructions, or at least context for the tracebacks.
Demand loaded graph
To keep refreshes as efficient as possible, the graphing algorithm will only load a couple hundred revisions initially during a refresh, and then load further revisions only when those revisions are required to be displayed. You will notice scrolling through the graph is jerky, these are bulk loads of revisions into the graph. To avoid this jerkiness you can force TortoiseHg to load all revisions in the graph via the Load all revisions option from the View menu.
A Quick Start Guide to TortoiseHg
Welcome to TortoiseHg and the Mercurial! TortoiseHg is a set of graphical applications and Windows Explorer shell extension that serve as a friendly front-end to the Mercurial distributed version control system (DVCS).
All TortoiseHg functionality is reachable from 3 places:
-
The Workbench application
You can start the Workbench from the Start Menu, or by right clicking on the Desktop and selecting .
Start the Workbench from the Desktop
-
The Explorer context menu
All you have to do is right click on the right folder or files in Explorer, and select a context menu entry.
-
The thg command line application
Type the appropriate commands from any command line interface, in the form thg <command> [options].
In this quick guide we would like to make you get started using the Workbench application, but we will also indicate how to do the same with the other possibilities.
Mercurial commands are also available from the standard hg command line application.
4.1. Configuring TortoiseHg
Your first step should be to make sure that you are correctly identified to TortoiseHg. You do this by opening the global settings dialog.
Workbench: select from the menu
Explorer: choose from the context menu
Command line: type thg userconfig
This opens the TortoiseHg settings dialog, editing your global (user) configuration.
TortoiseHg Settings Dialog
First select the Commit page and enter a name in the Username field.
Note
If you neglect to configure a username TortoiseHg will ask you to enter one when you try to commit, which is the first time a username is actually required.
Note
There are no hard fast rules on how to format your username, the field is free form, but the following convention is commonly used:
FullName <email>
for example
Donald Duck <donaldduck@example.net>
The email address is stripped when viewing history in the revision history viewer, and the built-in web server obfuscates email addresses to prevent SPAM.
Next, select the TortoiseHg page and select the Three-way Merge Tool entry. In the drop down list you will find all of the merge tools detected on your computer (kdiff3 is provided by the Windows installer) and a number of internal merge behaviors. Select your preferred merge tool.
If you prefer for TortoiseHg to also use your selected merge tool for visual diffs, you can leave the Visual Diff Tool unspecified. Otherwise, select your favorite visual diff tool from the drop down list of detected visual diff tools.
If there are no options in either drop-down list, you must install a diff/merge tool that is supported by our mergetools.rc or configure your own tool.
Note
If you installed TortoiseHg from source, you need to add our contrib/mergetools.ini file to your HGRC path in some way. One approach is to %include it from your ~/.hgrc file.
Feel free to configure other global settings while you have the dialog open. You will have the chance later to override these global settings with repository local settings, if required.
Click the OK button to save the changes you have made and close the settings dialog.
Note
Most TortoiseHg settings changes are noticed immediately, but loading or unloading extensions usually requires restarting all open applications for the changes to take effect.
Getting Acquainted
Mercurial supports many different collaboration models. This chapter describes just one of those models: a single central repository. The central repository model does not scale as well as other models, but it is the most familiar to those coming from other revision tools and thus is the most common approach people start with.
To get started, suppose you volunteer to create the central repository. There are ways to convert non-Mercurial repositories into Mercurial repositories, but this example assumes you are starting from scratch.
Initialize the repository
Create the initial repository on your local machine:
Workbench: select from the menu
Explorer: select from the context menu
Command line: type thg init
You can do this from within the folder you want to create the repository in, or enter the correct path in the dialog. You only need to do this once in the root folder of your project.
Repository Init Dialog
We suggest you keep Create special files (.hgignore, …) checked, and do not check Make repo compatible with Mercurial < 1.7, unless you have a strong reason to do so.
After pressing Create, Mercurial creates a subdirectory in your project folder named .hg. This is where Mercurial keeps all its version data. It is called the repository or store, while the directory containing the source files is called the working directory. You never need to specify the .hg directory when running commands, you only need to specify the working directory root. It is mentioned here just so you better understand how Mercurial works.
The new repository will also be added to the RepoRegistry when you perform this operation from the Workbench.
Warning
It is dangerous to manually edit the files in .hg directory, repository corruption can occur. .hg/hgrc is perhaps the only exception to this rule.
Note
Perhaps you already created one or more repositories. As you can manage multiple repositories in the Workbench at the same time, you can add these existing repositories by selecting from its menu, and selecting their folder. Or you could drag their folder from Explorer into the RepoRegistry pane.
Add files
Now it’s time to tell Mercurial which files must be tracked. There are various ways to do this:
- Workbench: goto the Commit task tab, rightclick on the file, and select from the context menu. This will change the status indication of that file into ‘A’ and the filename will turn green.
- Explorer: select in the context menu. A dialog will open for you to check the selected files and accept the add operation. You can also open the status tool by selecting . Check the files you want to add and select Add from the file context menu.
- Command line: type thg status
- Or skip adding new files as a separate step and have the commit tool add them implicitly. The commit tool is very similar to the status tool and allows you to do all of the same tasks. In this tool you can add and commit an untracked file by just checking the file and pressing Commit.
Ignore files
You may have some files in the foldertree of your repository that you don’t want to track. These can be intermediate results from builds f.i. that you do not wish to always delete immediately, or files your editor generates, etc. You can mark these files as ignored in some different ways too.
- Workbench: goto the Commit task tab, rightclick on the file, and select from the context menu to open the ignore filter dialog.
- Explorer: select .
- Command line: type thg hgignore to bring up the ignore filter dialog.
- You can also launch the ignore filter from the status tool (the menu option is named Ignore).
Choose a file from the list or manually type in a Glob or Regular expression filter and then press Add. Changes to the ignore filter take effect immediately.
Note
The .hgignore file, contained in the working directory root, is typically tracked (checked in).
Note
It is good practice to not have many unknown files in your working directory, as it makes it too easy to forget to add vital new files. It is recommended that you keep your .hgignore file up to date.
Commit
Commit your local repository now:
Workbench: click on the Working Directory revision which also selects the Commit task tab, or directly select the Commit task tab
Explorer: right-clicking anywhere in the folder, or on the folder itself, and then selecting Hg Commit…
Command line: type thg commit
Write a commit message, select the files you wish to commit, then press Commit. Your previous commit message will be in the message history drop-down, so you do not have to type it in again from scratch.
Commit Tool
4.7. Share the repository
Now you are ready to share your work. You do this by making a copy of your repository in a public location that everyone in your group can read. Mercurial calls this copy operation cloning your repository.
To clone your repository to a shared drive:
Workbench: select from the menu
Explorer: select from the context menu
Command line: type thg clone
Then enter the destination path, and click Clone.
Clone Dialog
When you create a clone for the purposes of generating a central repository there is no reason for that clone to have a working directory. Checking Do not update the new working directory under Options will prevent Mercurial from checking out a working copy of the repository in the central repository clone. It will only have the .hg directory, which stores the entire revision history of the project.
Other team members can clone from this clone with or without a checked out working directory.
Fetching from the group repository
You want to start collaborating with your team. They tell you something like fetch the repository from x. What does that mean? It means that you want to make a copy of the repository located at x on your local machine. Mercurial calls this cloning and TortoiseHg has a dialog for it.
Workbench: select from the menu
Explorer: select from the context menu
Command line: type thg clone
Then enter the destination path, and click OK.
Clone Dialog
This time you do want to update the working directory because you want to work on the project, under Options uncheck Do not update the new working directory so Mercurial updates the working directory with the tip revision in your new clone.
4.9. Working with your repository
Suppose you’ve introduced some changes. It is easy to discover what pending changes there are in the repository.
Workbench: go to the Commit task tab and inspect the filelist at the left
Any files marked with ‘A’ (added, green), with ‘?’ (unversioned but not ignored, fuchsia), with ‘M’ (modified, blue), or with ‘!’ (removed, red) indicate pending changes that should be committed.
The Commit task tab in the Workbench gives you a way to see differences within the files, or you can use your visual difference tool (kdiff3). Mercurial allows you to commit many changes before you decide to synchronize (share changes) with the group repository.
Explorer: inspect the icons on the folders and files in your repository
Folders or files in Explorer marked with one of the icons below are another way of indicating pending changes. You can traverse the directories to find specific changes and commit them from Explorer. Though it might be quicker to do that from the Commit task tab in the Workbench.
Overlay Icons on Vista
Command line: type thg commit
When you’re ready to publish your changes, you
- Commit your changes to your local repository (see above).
- Pull changes from the group repository into your repository using or thg log, select the Sync task tab, choose the path to the group repository in the syncbar and then click the Pull button.
- If some changesets were pulled, merge those changes with your local changes and then commit the merge into your local repository. From the revision history viewer ( or thg log) open the context menu over the changeset which you want to merge and select Merge with local…. Finally, in the merge dialog, press Merge and then Commit.
- Ensure your merged work still builds and passes your extensive test suite.
- Push your changes to the group repository, or thg log, select the path to group repository and then click the Push button.
Which may sound complicated, but is easier than it sounds.
Merges can be safely restarted if necessary.Mercurial makes collaboration easy, fast, and productive.
TortoiseHg is a set of graphical tools and a shell extension for the Mercurial distributed revision control system.
How To Install “tortoisehg” Package on Ubuntu:
Quick Install Instructions of tortoisehg on Ubuntu Server. It’s Super Easy! simply click on Copy button to copy the command and paste into your command line terminal using built-in APT package manager.
See below for quick step by step instructions of SSH commands, Copy/Paste to avoid miss-spelling or accidently installing a different package.
Quick Install Steps:
sudo apt-get update -y
sudo apt-get install -y tortoisehg
Check the system logs to confirm that there are no related errors.
Note: -y flag means to assume yes and silently install, without asking you questions in most cases.
On Windows,TortoiseHg consists of the Workbench graphical application, a shell extension which provides overlay icons and context menus in your file explorer, and a command line program namedthg.exe which can launch the TortoiseHg tools. Binary packages of TortoiseHg for Windows come with Mercurial and a merge tool and are thus completely ready for use “Out of the Box”.
Detailed Instructions:
Step 1
Run update command to update package repositories and get latest package information.
sudo apt-get update -y
sudo apt-get install -y tortoisehg
On Linux,TortoiseHg consists of a command line thg script and a Nautilus extension which provides overlays and context menus in your file explorer. You must have Mercurial installed separately in order to run TortoiseHg on Linux. TortoiseHg binary packages list Mercurial as a dependency, so it is usually installed for you automatically.
TortoiseHg is primarily written in Python and PyQt (the Windows shell extension being the notable exception). The thg script and TortoiseHg dialogs can be used on any platform that supports PyQt, including Mac OS X.
Features
Major Features of TortoiseHg:
- Repository explorer
- Commit dialog
- Support for visual diff/merge tools.
- Data mining on repository contents
- Seamless support for serving a repository via Mercurial’s integrated web interface.
- Repository synchronization
- Intuitive GUI for managing Mercurial setting
Common Features
These features are common to many TortoiseHg tools, so we document them here just once.
5.1.1. Visual Diffs
Visual Diff Window
In TortoiseHg 1.0, the visual (external) diff infrastructure was refactored. The new system uses tool descriptions in mergetools.rc to detect most common diff tools on your computer (including KDiff3, which ships in our installer) and select the best available tool.
If the user has selected a merge tool (), that tool will also be used to perform visual diffs, bypassing the tool selection process. However the user can still select a separate tool () for visual diffs if they chose.
The merge tool configuration file contains optimal command lines for each tool, so no further configuration is required by the user. They only need to select the tools they wish use, or accept the defaults.
The visual diff system will use any existing extdiff configuration it finds. Since extdiff did not support three way diff arguments until very recently and still does not support label arguments, you will likely have a better experience by disabling or deleting any extdiff configuration you may have.
The visual diff system will directly use the selected diff tool unless the action you are attempting requires the use of the TortoiseHg visual diff window. The list of conditions includes:
- The selection of files being compared require multiple tools
- The selected tool forks detached background processes
- The selected tool does not support the required directory diffs
- The selected tool does not support three way comparisons
- The file changes include renames or copies
When the visual diff window is used, the temporary files are cleaned up when the dialog is closed. Thus it should be left open until you close all of your diff tool instances. When your diff tool is launched directly, the temporary files are deleted when your tool exits.
If your diff tool is launched directly to compare a working copy file, it will directly diff against the working file so you may modify it from within the diff tool. If you are comparing multiple files, the visual diff system will make a snapshot of the working copy files and track their initial sizes and timestamps. When your diff tool exits, the system compares the sizes and timestamps and copies modified files back over the original working copies. In this way, you can still modify your working copy files from your visual diff tool even when performing directory comparisons.
When the visual diff window is used to compare working copy files, it always directly diffs against the working copy files since it always operates on a single file at a time.
Deprecated since version 1.0: The configurable has been removed because it is now redundant.
Adding Tools
If you have a visual diff tool installed that is not supported by TortoiseHg, you can create a tool configuration for it in your user Mercurial.ini file. See Mercurial’s documentation on how to configure your tool for use in file merges. When that is complete, you can add the extra keys used by TortoiseHg for visual diff:
diffargs: the arguments to use for two-way file comparisons
diff3args: the arguments to use for three-way file comparisons
dirdiff: this tool supports two-way directory comparisons
dir3diff: this tool supports three-way directory comparisons
When building command line arguments, you can use the following variables:
$parent1: the file or directory from the first parent revision
$parent2: the file or directory from the second parent revision
$child: the file or directory from the revision being compared
$parent: a synonym for $parent1
$plabel1: a symbolic name for the first parent revision
$plabel2: a symbolic name for the second parent revision
$clabel: a symbolic name for the revision being compared
Obviously, $parent2 and $ancestor are only meaningful when used in three way diff arguments, for viewing merge changesets. If your diff tool cannot use the ancestor revision in any productive way, it is safe to leave it out of the diff3args command line.
Note
On Windows, the executable parameter can use environment variables using the syntax ${ProgramFiles}
If unconfigured, the default value of diffargs is ‘$parent $child’. The default value of diff3args is “”, indicating the visual diff tool cannot perform three way comparisons.
If you create a new visual diff tool configuration, or improve upon an existing configuration, please email it to our development mailing list so it may be incorporated in a future release.
Word Diffs
The TortoiseHg Windows installers now include TortoiseSVN’s scripts for comparing (and sometimes merging) many binary document formats. These are configured in the site-wide mergepatterns.rc as handlers for each binary format’s common file extensions, so no user intervention is required.In order to support file extension based tool selection, TortoiseHg has added support for a [diff-patterns]
Videos
Getting Started with TortoiseHG
