= Communicating Changes =

Mercurial has three distinct ways of communicating changes that are useful in different scenarios:

 * [[Cmd:push]] / [[Cmd:pull]] / Clone - native direct communication between repositories
 * [[Cmd:import]] / [[Cmd:export]] - generate and commit changes as patches
 * bundle/unbundle - exchange changes in the native internal file format

== push/pull/clone ==

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.


== import/export ==

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 <thomas@intevation.de>
# 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.

== bundle/unbundle ==

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
}}}
----
CategoryHowTo