Edit file $HOME/.hgrc with your preferences and enabled extensions (hg plugins), for example mine is

 [ui]
 merge = kdiff3
 username = Kai Engert <kaie@kuix.de>
 [defaults]
 diff=-U 8 -p
 qdiff=-U 8
 [diff]
 git = 1
 nodates = 1
 showfunc=true
 [merge-tools]
 kdiff3.args = $base $local $other -o $output
 [extensions]
 hgext.mq =
 rebase = 

cvs update -r otherrevision path/file

hg revert -r <otherrevision> path/file

If the old file was in a different directory (prior to a directory reorganization), then it must be done in two steps:

hg revert -r <otherrevision> old/path/file

cp old/path/file new/path/file

I think we would distinguish between lightweight branches for minor releases, and release repositories for each new major version. This would allow the NSS team to avoid dealing with the term branch most of the time. In other words, NSS trunk development would happen on https://hg.mozilla.org/projects/nss/ We would request a release repository (work done by Mozilla rel-eng?) each time we start a new major version, e.g.:

• https://hg.mozilla.org/releases/nss-3.13/
• https://hg.mozilla.org/releases/nss-3.14/
• https://hg.mozilla.org/releases/nss-3.15/

For each of the above https:// URLs you can use its own separate local directory, and you usually don't need to worry about branches.

If necessary, we can create named branches inside a respository, but most of the time it won't be necessary. We can simply create a minor release tag inside a repository and continue work on the main branch. The main branch inside a repository is named "default".

Each locally cloned tree must be prepared once before you can commit, by editing the file .hg/hgrc inside that directory. The file will already contain

[paths]
default = https://hg.mozilla.org/mozilla-central/

You must add another line like

default-push = ssh://kaie@kuix.de@hg.mozilla.org/mozilla-central/

Each time you commit, you must remember to do both commit and push, because HG allows you to commit many changes locally, and only push them afterwards.

If other people have commited and pushed since you updated your tree, you'll have to clean that up. There are easy instructions how to do that on Mozilla's Mercurial FAQ page. But using the following instructions for commit, it's unlikely to run into this scenario, given only few developers commit to NSS.

My suggestion is, never use "hg commit" directly, but instead run the combination of the following two commands:

 hg incoming || hg commit

This effectively means, "check whether anyone else has done changes in the meantime, if yes, then don't commit, if no, then go ahead and commit." If that aborted, simply update your local tree (hg pull -u), and hg will automatically merge in the remote updates, and then repeat your "incoming/commit", and you'll succeed.

I use a script named hgcommit.sh with the following contents:

 hg incoming || hg commit "$@"

Once that succeeds, immediately run "hg push", in order to minimize the risk of collisions.

(If you really ever run into a collision with NSPR/NSS, then follow the steps explained in the FAQ. Either a "merge commit" (which will create a noise entry in the changelog so many prefer to avoid it) or using the rebase extension or using a series of steps using the patch-queue extension (cannot remember, must follow the steps from wiki page).