|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|= Communicating changes =||= Communicating Changes =|
Mercurial has three distinct ways of communicating changes that are useful in different scenarios:
- bundle/unbundle - exchange changes in the native internal file format
This is the usual method of exchanging changesets between developers. It's fast and easy to use and works in most environments.
$ hg clone hg work requesting all changes adding changesets adding manifests adding file changes added 1218 changesets with 2690 changes to 195 files $ cd work $ hg pull ../local pulling from /home/example/local searching for changes adding changesets adding manifests adding file changes added 13 changesets with 20 changes to 6 files (run 'hg update' to get a working copy) $ hg up $ <make changes> $ hg ci $ hg push ssh://user@server/~/repo/hg/ pushing to ssh://user@server/~/repo/hg/ searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 3 changes to 3 files
It is possible to pull from completely unrelated repository, so you can, for example, pull a linux kernel repo into your Mercurial repo.
[vmg@xarn mercurial]$ hg pull --force http://www.kernel.org/hg/linux-2.6 pulling from http://www.kernel.org/hg/linux-2.6 searching for changes warning: pulling from an unrelated repository! ...
Subsequent pulls from linux repo will do the right thing, but when you push your Mercurial work upstream, upstream repository will get a copy of Linux too (which might not be what you intended to do). Nonetheless, this feature might be useful for assembling a few smaller projects into single larger project, and for maintaining "vendor branches" (if vendor uses Mercurial too). See also "The coolest merge EVER!" http://www.gelato.unsw.edu.au/archives/git/0506/5511.html
See PublishingRepositories for more information.
This method is useful for receiving small numbers of changes from contributors and is a traditional method for open source projects. This is primarily used in scenarios where changes get reviewed before being applied to a central repository.
In combination with the push/pull method, it's common to post patches generated by export to a mailing list, along with instructions for pulling from their source repository.
This can also be useful for "cherry-picking" individual patches from one repo into another.
$ hg export 1135 # HG changeset patch # User Thomas Arendsen Hein <email@example.com> # Node ID e455d91f62598b8f255ce6c0291afe8f8565e0d2 # Parent 2cd33ea2f66bae0eb7415cfcd7eab88566fdb1aa Variable 'body' was missing in patchbomb script. diff -r 2cd33ea2f66b -r e455d91f6259 contrib/patchbomb --- a/contrib/patchbomb Sun Aug 28 16:30:40 2005 +++ b/contrib/patchbomb Sun Aug 28 16:52:55 2005 @@ -107,6 +107,7 @@ def makepatch(patch, idx, total): desc =  node = None + body = '' for line in patch: if line.startswith('#'): if line.startswith('# Node ID'): node = line.split()[-1] $ hg export 1135 > ../body.patch $ cd ../work $ hg import ../body.patch
You can easily send these patches via email as well; see PatchbombExtension for details.
This method allows communication of patches by exchanging "bundles": a compressed group of changesets in a native file format. These bundle files can then be exchanged via email attachments, FTP, floppy disk, etc.
This also allows you to publish your changes without publishing a copy of the entire project history.
$ hg bundle changes.hg http://upstream/repo searching for changes $ scp changes.hg server:public_html $ cd ../other $ hg unbundle http://server/~user/changes.hg adding changesets adding manifests adding file changes added 13 changesets with 20 changes to 6 files