Often you won't have direct access to the repository of someone else, be it because he's behind a restrictive firewall, or because you live in different timezones. You might also want to keep your changes confidential and prefer internal email (if you want additional protection, you can also encrypt the emails, for example with GnuPG).

Often you won't have direct access to the repository of someone else, be it because he's behind a restrictive firewall, or because you live in different time zones. You might also want to keep your changes confidential and prefer internal email (if you want additional protection, you can also encrypt the emails, for example with GnuPG).

In that case, you can easily export your changes as patches and send them by email.

Sending changes by email might be the easiest way to reach people when you aren't yet part of the regular development team, but it creates additional workload: You have to bundle the changes, send mails and then import the bundles manually. Luckily there's an easier way which works quite well: The shared push repository.

Till now we transferred all changes either via email or via pull. Now we use another option: pushing. As the name suggests it's just the opposite of pulling: You push your changes into another repository.

Until now we transferred all changes either via email or via pull. Now we use another option: pushing. As the name suggests it's just the opposite of pulling: You push your changes into another repository.

By default hg serve doesn't allow pushing, since that would be a major security hole. You can allow pushing in the server, but that's no solution when you live in different timezones, so we'll go with another approach here: Using a shared repository, either on an existing shared server or on a service like BitBucket. Doing so has a bit higher starting cost and takes a bit longer to explain, but it's well worth the effort spent.

By default hg serve doesn't allow pushing, since that would be a major security hole. You can allow pushing in the server, but that's no solution when you live in different time zones, so we'll go with another approach here: Using a shared repository, either on an existing shared server or on a service. Doing so can have a bit higher starting cost and takes a bit longer to explain, but it's well worth the effort spent.

Otherwise you first need to setup a BitBucket Account. Just signup at BitBucket. After signing up (and login) hover your mouse over "Repositories". There click the item at the bottom of the opening dialog which say "Create new".

Give it a name and a description. If you want to keep it hidden from the public, select "private"

Now your repository is created and you see instructions for pushing to it. For that you'll use a command similar to the following (just with a different URL):

(Replace the URL with the URL of your created repository. If your username is "Foo" and your repository is named "bar", the URL will be https://bitbucket.org/Foo/bar/)

To see what you would get if you would push, you can use outgoing. It works with local repositories in the same way as with shared ones, so you can test it with a local one:

To see what you would get if you would push to a shared repository, you can use outgoing. It works with local repositories in the same way as with shared ones, so you can test it with a local one:

output of hg outgoing ../feature1 (our feature seperation repo): +

output of hg outgoing ../feature1 (our feature separation repo): comparing with ../feature1 searching for changes changeset: 6:3f549b33c7ef @@ -805,45 +787,14 @@

Note:

-You can also use SSH for pushing to BitBucket. +You can often use SSH for pushing to and pulling from publicly hosted shared repository services.

Now it's time to tell all your colleagues to sign up at BitBucket, too.

- -

After that you can click the "Admin" tab of your created repository and add the usernames of your colleagues on the right side under "Permission: Writers". Now they are allowed to push code to the repository.

- -

(If you chose to make the repository private, you'll need to add them to "Permission: Readers", too)

- -

If one of you now wants to publish changes, he'll simply push them to the repository, and all others get them by pulling.

- -

Publish your changes

- -

$ hg push https://bitbucket.org/ArneBab/hello/
-
-

- -

Pull others changes into your local repository

- -

$ hg pull https://bitbucket.org/ArneBab/hello/
-
-

- -

People who join you in development can also just clone this repository, as if one of you were using hg serve

- -

$ hg clone https://bitbucket.org/ArneBab/hello/ hello
-
-

- -

That local repository will automatically be configured to pull/push from/to the online repository, so new contributors can just use hg push and hg pull without an URL.

When you clone a remote repository to a local repository, it will automatically be configured to pull/push from/to the remote repository, so new contributors can just use hg push and hg pull without an URL.

Note:

-To make this workflow more scalable, each one of you can have his own BitBucket repository and you can simply pull from the others repositories. That way you can easily establish workflows in which certain people act as integrators and finally push checked code to a shared pull repository from which all others pull. -

- -

Note:

-You can also use this workflow with a shared server instead of BitBucket, either via SSH or via a shared directory. An example for an SSH URL with Mercurial is be ssh://user@example.com/path/to/repo. When using a shared directory you just push as if the repository in the shared directory were on your local drive. +You can also use this workflow with a self-hosted shared server instead of a public repository hosting service, either via SSH or via a directory that is shared between users on a private network (e.g., NFS or other network file sharing mechanisms). An example for an SSH URL with Mercurial is be ssh://user@example.com//path/to/repo. When using a shared directory you just push as if the repository in the shared directory were on your local drive. Consult the URL Paths documentation (hg help urls) for more information on specifying a path to a shared repository.

Summary

@@ -898,7 +849,7 @@

Workflow

Using the builtin webserver

Using the builtin web server

Sending changes by email

Summary

share your repository via the integrated webserver

share your repository via the integrated web server

Use shared repositories on BitBucket

Use shared repositories on a public repository sharing service