Contents
So I like the ideas behind Mercurial (cross-platformness, in Python, and meant to be an easier road for those moving from Subversion).
Which is excellent, and those three things might make Hg win over Git internally here.
http://hg-git.github.com/ <-- GitHub's plugin for Mercurial to allow you to push to git repos from Mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/HistpushExtension <-- no more git-wtf!
http://www.selenic.com/mercurial/wiki/index.cgi/ReviewboardExtension <-- easy posting to reviewboard
http://bitbucket.org/alu/hgtasks/wiki/Home <-- tasks (aka: better stashes!)
Mercurial Record Extension, allows the same kind of feature as git's staging area
NOTE: We've codified a lot of these into our own fork of configure-hgrc. This project will automatically set up your ~/.hgrc the way (we) like it.
Mercurial with adhoc groups of hackers
ZeroConf/Bonjour enabled hg serve
Mercurial Way Of Doing Things
BitBucket (or: changes up and downstream)
In .hg/hgrc there are paths for the remote repositories you are interested in:
you could set up one:
upstream = http://example.com/repo
Then you can:
hg pull upstream && hg update
and you will have the changes from the upstream repo changes
You can also use hgconfig to make this experience more pleasant.
hg config paths.upsteam http://example.com/repo
Mercurial Info/Debugging
Mercurial Character Encoding
Mac OS X Concerns / Work Arounds
Character Encoding on OS X information -- defaults to Mac Roman !!
Hg Version Information Into Builds
See this blog post for a shell script. NOTE that if your target SDK is not the current OS you'll need to surround this shell script with:
export MACOSX_DEPLOYMENT_TARGET_old=$MACOSX_DEPLOYMENT_TARGET export MACOSX_DEPLOYMENT_TARGET=10.5
at the top and
export MACOSX_DEPLOYMENT_TARGET=$MACOSX_DEPLOYMENT_TARGET_old
at the bottom (or else deep Python internals will have an issue)
Workflow
Merging
Merge with an explicit rev
In this situation Mercurial doesn't want a revision in the PAST, it wants the one in the future.
As as example
└─[$] <> hg heads changeset: 133:bd6d68d1ea0f tag: tip parent: 126:a206b77fd995 user: Ryan Wilcox <rwilcox@wilcoxd.com> date: Sat Feb 06 22:15:19 2010 -0500 summary: Fixed issue where opt2/opt3 scripts would be triggered on an upstroke changeset: 132:00b3a6d2da62 user: Ryan Wilcox <rwilcox@wilcoxd.com> date: Tue Jan 19 23:25:32 2010 -0500 summary: long debugging session of Applescript changes to make option keys better changeset: 98:1782deee1f86 user: Ryan Wilcox <rwilcox@wilcoxd.com> date: Fri Oct 09 23:07:59 2009 -0400 summary: product and vendor id for new keyboard changeset: 85:fbb2480533e4 branch: element_id_work user: Ryan Wilcox <rwilcox@wilcoxd.com> date: Thu Sep 24 13:04:02 2009 -0400 summary: adding element id database
r133 is the new changeset we just got from our remote repo. hg wants to know what tip you want to merge IN. So the proper command to give is:
hg merge -r 133
Ignoring personal files only in your working copy that you don't want to put in the groups's .hgignore
Resources
When you get a "wlock can not be deleted, is directory"
I've gotten this a few times.
- go into .hg and make *sure* that wlog isn't a symbolic link to the .hg directory. (If it is, removing this directory will kill your repository!!)
- If it *is* a directory, keep on reading. Else, exit.
- cd above the .hg directory
- mv .hg .hg_temp
- cd .hg_temp
- rm wlock
- cd ../
- mv .hg_temp .hg
Comments:
Add comments by visiting: Mercurial/Comments