Differences between revisions 4 and 12 (spanning 8 versions)
Revision 4 as of 2008-02-10 20:24:14
Size: 1551
Editor: abuehl
Comment: Refer to Merge page (nearly identical text)
Revision 12 as of 2012-11-06 15:04:49
Size: 2727
Editor: abuehl
Comment: remove link to deleted page "commit"
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
See [:Merge:merge] See documentation for the [[Merge|merge]] command.
Line 7: Line 7:
First, merge often! This makes merging easier for everyone and you
find out about conflicts (which are often rooted in incompatible
design decisions) earlier.

Second, don't hesitate to use multiple trees locally. Mercurial makes
this fast and light-weight. Typical usage is to have an incoming tree,
an outgoing tree, and a separate tree for each area being worked on.

The incoming tree is best maintained as a pristine copy of the
upstream [:Repository:repository]. This works as a cache so that you don't have to
[:Pull:pull] multiple copies over the network. No need to check files out here
as you won't be changing them.

The outgoing tree contains all the changes you intend for merge into
upstream. Publish this tree with {{{hg serve}}} or hgweb.cgi or use
{{{hg push}}}
to [:Push:push] it to another publicly availabe repository.

Then, for each feature you work on, create a new tree. Commit early
and commit often, merge with incoming regularly, and once you're
satisfied with your feature, pull the changes into your outgoing tree.
See some typical [[WorkingPractices|working practices]].
Line 32: Line 11:
See [:ConvertingRepositories] for various tips. See the [[ConvertingRepositories|Converting Repositories]] document for various tips.
Line 36: Line 15:
See [:WindowsInstall] for getting started using Windows. See the [[WindowsInstall|Windows install guide]] for getting started using Windows.

Like TortoiseSVN, [[http://www.selenic.com/pipermail/mercurial/2010-January/029680.html|we recommend]] to turn off the indexing service
on the working copies and repositories, and exclude them from virus scans.
Line 40: Line 22:
See [:GUIClients] for information on graphical merge tools and other front-ends. See the page of [[OtherTools|related tools]] for information on graphical merge tools and other front-ends.

=== How do I make sure that only known people can contribute/submit/commit/push changes? ===

Since Mercurial lets users do anything they want with their repository clones, sharing them with whoever they like, enforcing restrictions on commits is not generally possible with Mercurial (note, however, that committing in centralised version control systems' and Mercurial's commit operation are not exactly the same thing). However, the critical operation is actually the [[Push|push]] operation, since it is at such a point that changes are communicated between repository clones, and where an "official" repository would want to be able to reject "unverified" changesets: that is, changesets from people who are unknown or not authorised to contribute changes. So, although many clones may potentially exist with any individual (known or unknown) doing what they like, any work that makes its way to the "official" repository must have someone who is "verified" or "authorised" pushing that work; that person effectively takes responsibility for the work's suitability.

One extension which attempts to provide a verification capability is the [[CommitsigsExtension|commitsigs extension]].

(Although one can argue that in centralised version control systems, where each person has a login to a central repository, the task of verifying submitters is easier, there is also no guarantee that work submitted by another person has not somehow incorporated changes made by an "unauthorised" person. After all, it is possible to share the contents of repositories by other means - perhaps a user lets other people on a system access their checkout directly in the filesystem - and thus the act of submitting work by an "authorised" person is no guarantee that they did the work all by themself, merely that they take responsibility for it.)

How does merging work?

See documentation for the merge command.

What are some best practices for distributed development with Mercurial?

See some typical working practices.

How do I import from a repository created in a different SCM?

See the Converting Repositories document for various tips.

What about Windows support?

See the Windows install guide for getting started using Windows.

Like TortoiseSVN, we recommend to turn off the indexing service on the working copies and repositories, and exclude them from virus scans.

Is there a GUI front-end?

See the page of related tools for information on graphical merge tools and other front-ends.

How do I make sure that only known people can contribute/submit/commit/push changes?

Since Mercurial lets users do anything they want with their repository clones, sharing them with whoever they like, enforcing restrictions on commits is not generally possible with Mercurial (note, however, that committing in centralised version control systems' and Mercurial's commit operation are not exactly the same thing). However, the critical operation is actually the push operation, since it is at such a point that changes are communicated between repository clones, and where an "official" repository would want to be able to reject "unverified" changesets: that is, changesets from people who are unknown or not authorised to contribute changes. So, although many clones may potentially exist with any individual (known or unknown) doing what they like, any work that makes its way to the "official" repository must have someone who is "verified" or "authorised" pushing that work; that person effectively takes responsibility for the work's suitability.

One extension which attempts to provide a verification capability is the commitsigs extension.

(Although one can argue that in centralised version control systems, where each person has a login to a central repository, the task of verifying submitters is easier, there is also no guarantee that work submitted by another person has not somehow incorporated changes made by an "unauthorised" person. After all, it is possible to share the contents of repositories by other means - perhaps a user lets other people on a system access their checkout directly in the filesystem - and thus the act of submitting work by an "authorised" person is no guarantee that they did the work all by themself, merely that they take responsibility for it.)

FAQ/GeneralUsage (last edited 2012-11-06 15:04:49 by abuehl)