|
Size: 4134
Comment: Added explanatory diagrams.
|
Size: 7593
Comment: Added explanatory diagrams.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 36: | Line 36: |
| {{{#!dot digraph G { subgraph { node [shape="box"] rank=same start -> committed; } start -> checkout:w [label="update"]; checkout:e -> committed [label="commit"]; } }}} |
|
| Line 43: | Line 55: |
| }}} {{{#!dot digraph G { subgraph { node [shape="box"] rank=same competing [color="red"]; start -> competing -> committed; } start -> checkout:w [label="update"]; competing -> checkout:n [label="update"]; checkout:e -> committed [label="commit"]; } |
|
| Line 60: | Line 86: |
| {{{#!dot digraph G { subgraph { node [shape="box"] rank=same start1 [label="start"]; committed1 [label="committed"]; } subgraph { node [shape="box"] rank=same start2 [label="start"]; committed2 [label="committed"]; } checkout [label="working files"]; start1 -> committed1; start2 -> committed2; start1 -> start2 [label="pull"]; start2 -> checkout:w [label="update"]; checkout:e -> committed2 [label="commit"]; committed2 -> committed1 [label="push"]; } }}} |
|
| Line 66: | Line 116: |
| Note that before pushing changes, the developer is free to commit as many [[ChangeSet|changesets]] as they like. If `hg push` complains about multiple heads, the following workflow becomes necessary: | Note that before pushing changes, the developer is free to commit as many [[ChangeSet|changesets]] as they like without being affected by people working elsewhere. {{{#!dot digraph G { subgraph { node [shape="box"] rank=same start1 [label="start"]; competing1 [label="competing"; color="red"]; } subgraph { node [shape="box"] rank=same start2 [label="start"]; committed2 [label="committed"]; committed3 [label="..."]; } subgraph { rank=same checkout [label="working files"]; checkout2 [label="..."]; } start1 -> competing1; start2 -> committed2; committed2 -> committed3; start1 -> start2 [label="pull"]; start2 -> checkout:w [label="update"]; checkout:n -> committed2 [label="commit"]; checkout:e -> checkout2:w; checkout2:e -> committed3 [label="commit"]; } }}} When pushing, however, `hg push` may complain about multiple heads being created which means that the content of the repository has been edited in different ways and has not been reconciled. Multiple heads can exist in the remote repository, but this leaves any work for reconciling the competing changes for later, which may not be desirable. {{{#!dot digraph G { rankdir=LR node [shape="box"] start; subgraph { rank=same competing [color="red"]; committed; } start -> competing; start -> committed; } }}} To reconcile competing changes, the following workflow becomes necessary: |
| Line 78: | Line 178: |
| {{{#!dot digraph G { subgraph { node [shape="box"] rank=same start1 [label="start"]; competing1 [label="competing"; color="red"]; committed1 [label="committed"]; } subgraph { node [shape="box"] rank=same start2 [label="start"]; cc [shape="none"; label=< <table border='0' cellspacing='10' cellpadding='10'><tr><td port='competing2' border='1' color='red'>competing</td></tr><tr><td port='committed2' border='1'>committed</td></tr></table> >]; committed3 [label="committed"]; } subgraph { rank=same checkout [label="working files"]; checkout2 [label="..."]; } start1 -> competing1 -> committed1; start1 -> start2 [label="pull"]; start2 -> cc:competing2 -> committed3; start2 -> cc:committed2 -> committed3; start2 -> checkout:w [label="update"]; checkout:n -> cc:committed2 [label="commit"]; competing1 -> cc:competing2 [label="pull"]; checkout:e -> checkout2:w; cc:competing2 -> checkout2 [label="update"]; checkout2:e -> committed3 [label="commit"]; committed3 -> committed1 [label="push"]; } }}} |
CVS-like Working Practice
Mercurial allows multiple working practices. In a CVS-like world, you will typically have one central repository; let's call it the "main line". This corresponds to CVS's notion of the "trunk".
Repositories tend to be long-lived, and the "authoritative branches" are clones of the central repository.
Workflow
Developers have direct SSH access (whether that is through "normal" SSH access with each developer having their own login, or through shared SSH logins) to the central repositories on a server, and push their changes directly from their local clones into the appropriate repositories. Thus, the usual CVS practice would be as follows:
# Check for work done... cvs update # Do work, consider changes... cvs diff # Commit changes... cvs commit
This doesn't always work out, and so the following workflow is typically required if cvs commit complains:
# Rectify conflicts, then... cvs update # Edit conflicts, then commit... cvs commit
The corresponding practice would be as follows with Mercurial:
# Check for work done (part of the update operation in CVS)... hg pull # Start working with the latest changes (part of the update operation in CVS)... hg update # Do work, consider changes... hg diff # Commit changes (part of the commit operation in CVS)... hg commit # Push changes (part of the commit operation in CVS)... hg push
If you do not perform the hg update you can keep working and ignore other people's work - it will be available in your own clone - but ultimately you are likely to want to combine your own work with theirs. The single command equivalent of cvs update is really...
hg pull -u
Note that before pushing changes, the developer is free to commit as many changesets as they like without being affected by people working elsewhere.
When pushing, however, hg push may complain about multiple heads being created which means that the content of the repository has been edited in different ways and has not been reconciled. Multiple heads can exist in the remote repository, but this leaves any work for reconciling the competing changes for later, which may not be desirable.
To reconcile competing changes, the following workflow becomes necessary:
# Get the remote changes and merge them... hg pull hg merge # Edit any conflicts, then commit... hg commit # Push merged changes... hg push
Again, the developer can defer pushing changes until later. The principal advantage of Mercurial here is that the developer need not be confronted with merging others' changes on every commit.
Branches and merging
Someone may be responsible for "backporting" changes from a branch to the main line. They do this by pulling changes from the branch and the main line into a local repository, merging appropriately, then pushing back to the main line.
When the main line reaches a release point, someone creates a clone on the server at the appropriate revision, and people who need to work on that branch clone it, then start pushing their changes back.
See also
CVS commands and their equivalents in Mercurial