Differences between revisions 2 and 3
Revision 2 as of 2008-02-10 09:30:41
Size: 2615
Editor: abuehl
Comment:
Revision 3 as of 2008-02-10 19:15:17
Size: 2732
Editor: abuehl
Comment: links
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
The merge process is simple. Usually you will want to merge the tip
into your working directory. Thus you run {{{hg merge}}} and Mercurial
will incorporate the changes from tip into your local changes.
The [:Merge:merge] process is simple. Usually you will want to merge the [:Tip:tip]
into your [:WorkingDirectory:working directory]. Thus you run {{{hg merge}}} and Mercurial
will incorporate the changes from tip into your [:LocalModifications:local changes].
Line 8: Line 8:
changesets and finding the 'common ancestor' of the two versions that [:ChangeSet:changesets] and finding the 'common ancestor' of the two versions that
Line 22: Line 22:
are correct, it's a good idea to commit your changes. Mercurial won't are correct, it's a good idea to [:Commit:commit] your changes. Mercurial won't
Line 38: Line 38:
upstream repository. This works as a cache so that you don't have to
pull multiple copies over the network. No need to check files out here
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
Line 43: Line 43:
upsteam. Publish this tree with {{{hg serve}}} or hgweb.cgi or use upstream. Publish this tree with {{{hg serve}}} or hgweb.cgi or use
Line 45: Line 45:
to push it to another publicly availabe repository. to [:Push:push] it to another publicly availabe repository.
Line 54: Line 54:
See ConvertingRepositories for various tips. See [:ConvertingRepositories] for various tips.
Line 58: Line 58:
See WindowsInstall for getting started using Windows. See [:WindowsInstall] for getting started using Windows.
Line 62: Line 62:
See ["GUIClients"] for information on graphical merge tools and other front-ends. See [:GUIClients] for information on graphical merge tools and other front-ends.

How does merging work?

The [:Merge:merge] process is simple. Usually you will want to merge the [:Tip:tip] into your [:WorkingDirectory:working directory]. Thus you run hg merge and Mercurial will incorporate the changes from tip into your [:LocalModifications:local changes].

The first step of this process is tracing back through the history of [:ChangeSet:changesets] and finding the 'common ancestor' of the two versions that are being merged. This is done on a project-wide and a file by file basis.

For files that have been changed in both projects, a three-way merge is attempted to add the changes made remotely into the changes made locally. If there are conflicts between these changes, the user is prompted to interactively resolve them.

Mercurial uses a helper tool for this, which is usually found by the hgmerge script. Example tools include tkdiff, kdiff3, and the classic RCS merge.

After you've completed the merge and you're satisfied that the results are correct, it's a good idea to [:Commit:commit] your changes. Mercurial won't allow you to perform another merge until you've done this commit as that would lose important history that will be needed for future merges.

What are some best practices for distributed development with Mercurial?

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.

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

See [:ConvertingRepositories] for various tips.

What about Windows support?

See [:WindowsInstall] for getting started using Windows.

Is there a GUI front-end?

See [:GUIClients] for information on graphical merge tools and other front-ends.

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