|
Size: 1922
Comment: +cat, moving question
|
← Revision 46 as of 2013-08-31 09:38:15 ⇥
Size: 2656
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Mercurial working practices == | = Mercurial Working Practices = |
| Line 3: | Line 3: |
| 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. | 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. These are a few tips for creating a scaleable workflow. |
| Line 5: | Line 5: |
| First, [:Merge:merge] often! This makes merging easier for everyone and you | First, [[Merge|merge]] often! This makes merging easier for everyone and you |
| Line 13: | Line 13: |
| {{{#!dot digraph G { upstream; subgraph { incoming; outgoing; rank=same } working; upstream -> incoming [label="pull"]; incoming -> working [label="pull"]; working -> working [label="update/merge"]; working -> outgoing [label="push"]; outgoing -> upstream [label="push or publish"]; } }}} |
|
| Line 14: | Line 30: |
| 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 |
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 19: | Line 35: |
| upstream. Publish this tree with {{{hg serve}}} or hgweb.cgi or use {{{hg push}}} to [:Push:push] it to another publicly availabe repository. |
upstream. Publish this tree with `hg serve` or [[PublishingRepositories|hgweb]] or use `hg push` to [[Push|push]] it to another publicly available repository. |
| Line 23: | Line 38: |
| Then, for each feature you work on, create a new tree. [:Commit] early | Then, for each feature you work on, create a new tree. Commit early |
| Line 27: | Line 42: |
| === Other ways to collaborate === | == Other ways to collaborate == |
| Line 34: | Line 49: |
| === See also === * How to write good ChangeSetComments * RepositoryNaming is important, because you'll probably have lots of them * [:Clone] |
[[ContributingChanges|Mercurial development practices]] resemble those described in KernelPractice. |
| Line 39: | Line 51: |
| ---- Question by AiBin: Do you know which is the one HG takes itself? |
== Backup practices == To maintain a backup of commits, you can clone a repository and push your changes to it periodically. == See also == * How to write good [[ChangeSetComments|changeset comments]] * The [[RepositoryNaming|naming of repositories]] is important, because you'll probably have lots of them * Dealing with contributions from [[MultipleCommitters|multiple committers]] * More [[Workflows]] with usecase and requirements |
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. These are a few tips for creating a scaleable workflow.
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. 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 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 or use hg push to push it to another publicly available 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.
Other 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 |
Mercurial development practices resemble those described in KernelPractice.
Backup practices
To maintain a backup of commits, you can clone a repository and push your changes to it periodically.
See also
How to write good changeset comments
The naming of repositories is important, because you'll probably have lots of them
Dealing with contributions from multiple committers
More Workflows with usecase and requirements