On 04/26/2013 06:11 PM, Matt Brubeck wrote:
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. :)
[…]
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. :(
Such as maintaining a bi-directional hg-git mirror of multiple branches to
avoid having to deal with Mercurial at all?
When I discovered the poor resolution of conflicts offered my Mercurial
queues, I switched back to git. I have been pushing my patches to try &
inbound & aurora and beta with git since December 2011.
Back on the original subject:
1/ Having to deal with yet another Inbound would be a pain for all
automation testing such as Are We Fast Yet machines as we are making our own
builds out of inbound. This imply that our automation will have to switch
repositories to follow the latest patches such as we can keep a minimal
regression range. In addition, AWFY is often ahead of tbpl in terms of
build, which means that switching from inbound1 to inbound2 will mean going
backward in time, as patches would be back-ported to inbound2 as soon as
they are ok on inbound1. This is definitely weird.
2/ What happens if A & B changes are exclusive? A is pushed to inbound1,
inbound1 is closed for another reason. B is pushed to inbound2. A finish
building is cherry-picked from inbound1 and put on top of inbound2.
inbound2 fails because A does not build on top of B. Conclusion: both
branches are closed, and A have to be backed out even if it came first.
3/ Being a git guy, I prefer having a try-like server where you don't get
push contention or closed tree, because we are creating a new head
every-time, and let the sheriffs cherry-pick the good changes which are not
source of conflicts. And ask developers to rebase their changes otherwise.
--
Nicolas B. Pierron
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
