On 7/29/13 8:06 PM, Benjamin Smedberg wrote:
On 7/29/2013 1:43 PM, Gregory Szorc wrote:
I don't particularly care for our model of a single Mercurial
repository per logical entity. I think it makes sense for things like
twigs and to some extent integration repositories - you can do your
work in your own little world without disrupting others. But for all
the release branches, I think the model is suboptimal.
I'm proposing that we merge all the release repositories (central,
aurora, beta, release, esr, and b2g) into a single Mercurial
repository. The "default" branch/bookmark of this repository would be
the equivalent of mozilla-central. At train uplift time, we create a
new branch (or bookmark) called gecko-N (or similar) where N is the
core gecko/platform release version. If default/central is on 25,
Aurora changes land in gecko-24, Beta in gecko-23, etc. These could be
supplemented with build and release tags/branches as appropriate.
A benefit of this model is it introduces a linear repository history
for release branches. Contrast this with today, where we do non
fast-forward pushes at uplift time as a new "default" head becomes
aurora, beta, etc. gecko-25 is always "Firefox" 25 as it rides the
trains: it doesn't go through an identity crisis as it crosses channels.
Another benefit is it's a single repository. Wouldn't it be nice to
have the full history of all landings for released code in one unified
location rather than spread out over multiple repositories? I think it
would. I know it would have better performance characteristics than
maintaining multiple repos (reducing round trips, data duplication,
etc). These are all reasons I've switched to a monolithic/unified
repository for local development (just like the Github mirror).
A downside of this approach (other than that it is work to change) is
people may not realize which version aurora, beta, etc are on.
However, that can easily be corrected with tools. e.g. |hg land beta|
or even having friendly channel tags/aliases mirroring the core
version numbers.
Anyway, I believe the decisions on repository structure were made many
years ago, apparently due to limitations in now ancient versions of
Mercurial. Times have changed. I think we should revisit old decisions.
I'm certain that we would do things differently if we had it to do over
from scratch. But that there is enough reward here to be worth making a
change.
A perhaps-obvious downside to making any change here is that it will
require the releng machinery to change significantly: instead of
checking out the aurora/beta branch, at every merge point something will
have to be configured to check out a new branch/bookmark.
You've already demonstrated that any user who wants can already have the
"single repository" benefit by pulling multiple release repos into one
local tree.
Given all the things that we could be doing instead, why is this
important to do now?
--BDS
Also, the l10n automation infrastructure would need to be rewritten, and
a healthy amount of the tooling we put on top.
I'd expect the depth of the changes required in automations to be on par
with switching to git wholesale, tbh.
Axel
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
