This section describes the different sections that may appear in a Mercurial "hgrc" file, the purpose of each section, its possible keys, and their possibleĪlias Defines command aliases. Filenames are relative to the configuration file in which the %include directive is found.Ī line with %unset name will remove name from the current section, if it has been set previously. The inclusion is recursive, which means that includedįiles can include other files. Lines beginning with # or are ignored and may be used to provide comments.Ī line of the form %include file will include file into the current configuration file. If the lines that follow are indented, they are treated as continuations of that entry. Registry keys contain PATH-like strings, every part of which must reference a Mercurial.ini file or be a directory whereĪ configuration file consists of sections, led by a header and followed by name = value entries:ĮggsEach line contains one entry. Options in these files apply to all Mercurial commands executedīy any user in any directory. Per-installation/system configuration files, for the system on which Mercurial is running. (Windows) HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial Options in these files apply to all Mercurial commands executed by any user in any directory. For example, if installed in /shared/tools/bin/hg, Mercurial will look in Per-installation configuration files, searched for in the directory where Mercurial is installed. Options in these files override per-installation options. Options in these files apply to all Mercurial commands executed by any user inĪny directory. Per-system configuration files, for the system on which Mercurial is running.
Options in these files override per-system and per-installation options. To all Mercurial commands executed by this user in any directory.
#CHECK FOR MODIFICATIONS TORTOISEHG WINDOWS#
On Windows 9x, %HOME% is replaced by %APPDATA%. Per-user configuration file(s), for the user running Mercurial. See the documentation for the trusted section below for more details. On Unix, most of this file will be ignored if it doesn't belong to a Options in this file override options in all other configuration files. This file is not version-controlled, and will not get transferred during a Per-repository configuration options that only apply in a particular repository. Where multiple paths are given below, settings *.rc files from a single directory are read in alphabetical order, later ones overriding earlier ones. The names of these files depend on the system on which Mercurial is installed. Mercurial reads configuration data from several files, if they exist. The Mercurial system uses a set of configuration files to control aspects of its behavior. $rRepoRoot = Resolve-HgRoot -Path $RepoRoot # The path to the repository that should by synced. # Specifies an explicit repository to push to. If Mercurial does need to prompt, it will fail instead. When set, ensures Mercurial doesn't prompt for anything. # The synchronization is running in non-interactive mode. Adds the `-f` argument to the `hg push` command. # Forces the push, even if it will create multiple heads. Only this boookmark and changesets before it are pushed. Adds the `-new-branch` argument to the `hg push` command. The repository at `C:\Projects\PsHg` will be synchronized with its remote repository. PS> Sync-HgRepository -RepoRoot C:\Projects\PsHg The local repository in the current directory will be synchronized with its remote repository. If the synchronization succeeds, sets the `$PsHg?` variable to `$true`. Returns the output of the the Mercurial push commands it runs. If a pull brings in multiple heads in another branch, the script will stop and you�ll have to go to that branch, merge those heads, then re-run Sync-HgRepository.ps1. Once you commit the merge, you can re-run Sync-HgRepository.ps1.
If the merge results in any conflicts or merged files, the script stops so you can resolve the conflicts and review the merged files. It repeats until the push succeeds or fails and there are no incoming changes. If the push fails because there are incoming changes, it pulls those changes down, merges them, commits the merge (if there were no conflicts or merged files), then tries to push again. As long as a merge doesn't make any new, local modifications, the pull/merge/commit/push cycle will repeat until the push succeeds.
This script combines all these operations. Hg commit -m "My change are done! Woot!"Ībort: push creates new remote head addbadbeddadĪnd sometimes you have to repeat the pull/merge/commit/push cycle multiple times.
0 kommentar(er)
