On 4/26/2013 4:14 PM, Justin Lebar wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2? Would I
need to have an up-to-date inbound2 clone and transplant the patch
across?
I think mbrubeck or someone knows how to maintain multiple hg branches
in one repo, but I've never figured that out...
Yes, having been a git user for years before I started with Mercurial, I
simply treat Mercurial as a slightly crippled version of git. :)
hg clone https://hg.mozilla.org/mozilla-central/
cd mozilla-central
# hack on some stuff
# do some builds and tests
hg new my-patch
# time to push to inbound:
hg qpop
hg pull https://hg.mozilla.org/integration/mozilla-inbound/
hg up -c
hg qpush && hg qfin my-patch
hg push -r tip https://hg.mozilla.org/integration/mozilla-inbound/
# Now, let's backport something to Aurora!
hg pull https://hg.mozilla.org/releases/mozilla-aurora/
hg export -r a3c55bdbe37d | hg qimport -P -n patch-to-uplift
hg push -r tip https://hg.mozilla.org/releases/mozilla-aurora/
# After a good night's sleep, back to work!
# hg pull -u won't work across branches, so:
hg pull https://hg.mozilla.org/mozilla-central/
hg up -c
# do a build
# start hacking again!
This sort of workflow is of course much more natural in git, which makes
it easy to track the state of the remote repo(s). The bookmark workflow
that gps added to MDN basically emulates part of the functionality of
git remote tracking branches.
I'm actually astounded that Mercurial doesn't have better support for
this built in; I see Mozilla developers doing crazy time-consuming
things all the time because of Mercurial's poor support for working with
remote repositories. :(
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
