|
Size: 709
Comment: Typical of corporate processes
|
Size: 1860
Comment: Merge from page FAQ/GeneralUsage
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 14: | Line 14: |
=== 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. |
Mercurial working practices
This page documents some ways to use Mercurial. Because the software is flexible, there's no "right way", but some methods are more scalable than others.
How to write good ChangeSetComments
RepositoryNaming is important, because you'll probably have lots of them
Ways to collaborate
Name |
Scalability |
Overhead |
Description |
poor |
low |
keep things simple, use a few central repositories |
|
good |
medium |
distributed, semi-hierarchical development |
|
good |
medium |
hierarchical development |
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.