We are currently indexing your data, so search results may be incomplete until we finish.
stable
sync: update sync documentation, including a new security section
Needs a new screen shot and more updates, but this is a large improvement.
Changeset 8bf37de1fc6e…
Parent 111f60037ae9…
by
Changes to one file · Browse files at 8bf37de1fc6e Showing diff from parent 111f60037ae9 Diff from another changeset...
|
|
|
@@ -9,11 +9,6 @@
Synchronize dialog
-.. note::
- The synchronize tool has been deprecated in the 0.9 release, and may
- be removed in a future release. We suggest you use the changelog
- tool for performing synchronization duties.
-
The synchronize tool is used to transmit changesets between repositories
or to email recipients.
@@ -31,25 +26,8 @@ *tip* the new *tip* in the target repository
:guilabel:`Email`
send outgoing changesets (to target repository) as email
- :guilabel:`Shelve`
- launch the shelve tool to allow working changes to be
- temporarily moved into the shelf, since some operations require
- the working directory to be clean.
:guilabel:`Stop`
stop current operation
- :guilabel:`Configure`
- configure repository paths (aliases)
-
-Below the toolbar are two buttons and a text entry:
-
- :guilabel:`Repo:`
- browse for a local repository to synchronize with
- :guilabel:`Bundle:`
- browse for a local bundle file to pull from
-
-The text entry/combo box is where you enter or select paths of target
-repositories. The synchronize tool will seed the drop-down list with
-path aliases configured for this repository.
The :guilabel:`Post Pull Operation` frame contains radio buttons for
selecting the operation which is performed after a pull. This behavior
@@ -57,27 +35,28 @@default behavior for your user account and override that selection on a
per-repository basis.
- :guilabel:`Nothing`
+ :guilabel:`None`
No operations are performed after a pull. You will be allowed to
view the pulled changesets in the log viewer, and you will have the
option to update to the new tip if applicable.
:guilabel:`Update`
- Automatically update to the new branch tip if, and only if, new
+ Automatically update to the current branch tip if, and only if, new
revisions were pulled into the local repository. This could trigger
a merge if the pulled changes conflict with local uncommitted
changes.
:guilabel:`Fetch`
Equivalent to hg fetch. See the fetch extension documentation for
- it's behavior. This feature is only available if the fetch
+ its behavior. This feature is only available if the fetch
extension has been enabled by the user.
:guilabel:`Rebase`
Equivalent to pull --rebase. See the rebase extension
- documentation for it's behavior. This feature is only available
+ documentation for its behavior. This feature is only available
if the rebase extension has been enabled by the user.
-
-The :guilabel:`use proxy` button is a quick way to disable your proxy
-configuration for individual operations. The button is only sensitive
-when an http proxy is configured.
+ :guilabel:`Automatically resolve merge conflicts where possible`
+ If update or rebase are selected, a pull operation may result in
+ a merge. If checked, Mercurial will try to resolve trivial
+ merge conflicts without user interaction. If not checked, all
+ merges will be interactive.
All operations which require authentication will pop up dialog boxes to
get the required information from the user. TortoiseHg uses the
@@ -87,34 +66,20 @@
.. _FAQ: http://bitbucket.org/tortoisehg/stable/wiki/FAQ#tortoisehg-faq
-Under the :guilabel:`Advanced Options` fold-up panel are a number of
+Under the :guilabel:`Options` fold-up panel are a number of
configurables that are valid for most push/pull operations.
+ :guilabel:`Allow push of a new branch`
+ allow a new named branch to be pushed
:guilabel:`Force pull or push`
override warnings about multiple heads or unrelated repositories
- :guilabel:`Target Revision`
- to avoid sending all revisions
+ :guilabel:`Recurse into subdirectories`
+ incoming or outgoing commands can recurse into subdirectories
+ and provide a full report
:guilabel:`Remote Command`
- provides -e argument
- :guilabel:`Show patches`
- show diffs in incoming and outging changes
- :guilabel:`Show Newest First`
- reverse order that changesets are listed
- :guilabel:`Show No Merges`
- filter out merge changesets from output (does not affect push/pull)
+ provides --removecmd argument
-After Pull
-----------
-
-After changesets are pulled into your repository, a buttons may appear
-at the bottom of the dialog:
-
- :guilabel:`Update to branch tip`
- Update your working directory to the new tip of the current branch
-
-The button will be hidden when it is not applicable.
-
Email
-----
@@ -125,12 +90,11 @@
The email dialog can be launched from two TortoiseHg tools.
-1) The changelog tool, in which case the user intends to email a single
- revision or a range of revisions.
+1) The Workbench, in which case the user intends to email a selection
+ of revisions.
2) The synchronize tool, in which case the user intends to email all
- outgoing changes to the current target repository (it's good practice to
- check the outgoing changes before launching the email dialog).
+ outgoing changes to the current target repository.
The :guilabel:`Send` button is obvious, and the :guilabel:`Configure`
dialog predictably opens the TortoiseHg Settings dialog to the email tab
@@ -143,6 +107,119 @@Please consult the Mercurial documentation for the differences between
plain patches, Hg patches, Git patches, and bundles.
+Security
+--------
+
+Mercurial (and TortoiseHg) support two secure protocols for exchanging
+data with remove servers. HTTPS (SSL) and SSH.
+
+HTTPS
+~~~~~
+
+There are two asymmetrical parts to a secure HTTPS connection. The
+first is authenticating yourself (the client) to the server, either via
+a username and passphrase or a certificate key. The second part of the
+secure connection is authenticating to yourself the identification of
+the server.
+
+Host Authentication
++++++++++++++++++++
+
+Prior to version 1.7, Mercurial ignored this half of HTTPS connection
+security. In version 1.7 it began warning that the server's certificate
+was not being verified. Starting with Mercurial version 1.7.3
+(TortoiseHG 1.1.7), the binary installers begain to include a CA
+certificate file so that HTTPS server certificates could be verified by
+the standard certificate authorities. We download our certificate
+authority file from http://curl.haxx.se/ca/cacert.pem.
+
+Mercurial version 1.7.5 introduced the ability to validate an HTTPS
+server's certificate against a stored fingerprint. TortoiseHg 2.0's
+synchronize tool has an HTTPS security dialog that allows you to select
+between using a host fingerprint or using the CA certificates.
+
+In theory, a host fingerprint is more secure than the CA certificates
+if you do not necessarily trust all of the signing authorities listed in
+the cacert.pem file. However you must be sure that the fingerprint you
+store is the correct fingerprint for the server to which you believe you
+are communicating.
+
+TortoiseHg 2.0 also allows you to select an insecure connection for a
+given host. This disables validation of the host's certificate but
+still uses an encrypted data stream (which was essentially the behavior
+of Mercurial pre-1.7 except for the warning messages).
+
+User Authentication
++++++++++++++++++++
+
+There are several mechanisms available for authenticating yourself to an
+HTTPS server. The simplest is to allow Mercurial to prompt you for the
+username and passphrase. However this quickly grows old as the two
+prompts are always made separately and each push operation can require
+multiple connections to be established.
+
+The next option is to encode the username in the URL so that Mercurial
+only prompts for a passphrase. This cuts the number of prompts in half,
+but is still annoying. If you do not wish to be prompted for the
+passphrase, it must be stored somewhere. Your choices, in increasing
+security, are:
+
+1) encode the clear-text passphrase in each HTTPS URL in your repository configuration files
+2) store the clear-text passphrase in your user configuration file
+3) use the mercurial_keyring extension to store the passphrase cryptographically
+
+Until recently, TortoiseHg only supported the first option in the
+graphical interface even though the second and third options were
+supported internally. TortoiseHg 2.0, we only support the latter two
+options in the graphical interface, and we do not allow the user
+configure the first option anymore. By default we strip the username
+and password off of URLs when they are saved.
+
+To migrate from the first option to the later options, select an HTTPS
+URL in the sync tool, open the security dialog and enter a username and
+passphrase for the host if none are configured, and save. Next save the
+URL itself and allow the save dialog to strip the user authentication
+data from the URL.
+
+.. note::
+ If the mercurial_keyring extension is enabled, the security dialog
+ will not allow you to enter a passphrase since you do not want to
+ store the passphrase in clear text in your configuration file if you
+ are going to later store it cryptographically.
+
+Options 2 and 3 use the [auth] section of your user configuration file
+to configure a single username and passphrase (or certificate key files)
+to authenticate to a given HTTPS hostname. The [auth] section supports
+many more configurations than this, see the man page for details.
+
+Once the mercurial_keyring extension has been enabled (and all
+applications are restarted), you can remove the HTTPS passphrases from
+all of your configuration files. Mercurial will prompt for the
+passphrase once, then store it cryptographically using the best back-end
+it can find for your platform.
+
+The mercurial_keyring extension requires the [auth] section to be
+configured for the host to which you are connecting, to provide the
+username. If your URL has an encoded username or passphrase, the
+[auth] section is ignored.
+
+SSH
+~~~
+
+SSH is a symmetrical peer-to-peer secure tunnel. SSH clients and
+servers have their own key management systems, so Mercurial does not get
+involved with password prompts when SSH is used. This is problematic on
+Windows and thus TortoiseHg bundles the TortosePlink SSH client with its
+Windows installers. TortoisePlink is a port of the Plink SSH client
+that uses dialog prompts for host-key authorizations and passphrase
+prompts. TortoisePlink (developed by the TortoiseSVN project) can use
+the other SSH tools that are part of the Plink toolchain, including the
+Pageant key agent.
+
+It is a known issue that TortoisePlink does not use compression in many
+scenarios, and thus is up to four times slower than openssh and other
+clients. TortoiseHg recommends the use of HTTPS for Windows clients.
+
From command line
-----------------
@@ -150,17 +227,13 @@
thg sync
- aliases: pull, push, incoming, outgoing, email
+ aliases: synchronize
- repository synchronization tool
+ Synchronize with other repositories
use "thg -v help sync" to show global options
The syntax is simple, no options or parameters are needed, except the
-global options. If the synchronize tool is started via push, outgoing,
-or email command aliases, it will automatically select the
-*default-push* URL if. For all other aliases the tool selects the
-*default* URL. If the selected URL is not found, it will use the first
-path it finds.
+global options.
.. vim: noet ts=4
|
Add a tag
Loading...