hg-git part ix: git repo naming, and why gecko.git has different branch names than gecko-dev

(Interrupting the shorter blog posts about features in the new vcs sync process, to talk a bit about discussions I've been having...)

We have three official git repos now:

• releases/gecko.git, which is partner-oriented, and our highest priority to keep sane (currently lives on git.m.o only),
• integration/gecko-dev, which is developer-oriented, and we want to offer a strong SLA for. It contains all release and inbound branches (currently lives on both github and git.m.o), and
• integration/gecko-projects, which contains mercurial repos without strict pre-commit hooks, and are periodically reset; RelEng reserves the right to reset the repo if these cause vcs-sync issues. (Currently on github only, due to the ease of resetting branches (or the entire repo).)

All three share the same SHAs for shared commits.

---

As for this recent, valid question: "Wow, that's a lot of complexity. Not worth just making a clean once-off break of renaming branches?" (In regards to how we name branches differently in gecko-dev and gecko.git.)

I originally wanted to name the branches after the trains, so gecko.git would be largely hands-off. If they want 1.2 code now, it's in aurora; if they want it after merge day, they'll need to pull from b2g26_v1_2. Easy enough. However, merge day would require careful communication and process timing across languages, companies, and timezones. All work is easier when it's someone else's, but on an objective level, communication and logistics can be more difficult than a technical solution. So now we point the v1.2 branch at trunk, then aurora, then b2g26_v1_2, and our partners can keep pointing at v1.2. And my vcs-sync configs are a little complex as a result of those branch names; a decent trade-off.

(So that's the why of the naming of things. I'm impressed you've read your way through nine of these (I assume). Insomnia?)

hg-git part x: relbranches and non-fastforward commits

(Resuming the shorter blog posts about features in the new vcs sync process...)

After I enabled beagle conversions in cron, I started getting some intermittent non-fastforward emails. When I poked around, I noticed that some changes had landed on GECKO90_2011121217_RELBRANCH on mozilla-release, but not mozilla-beta. When syncing mozilla-release, the tip of this branch stayed in place; when syncing mozilla-beta, the tip of this branch was behind several commits, resulting in a non-fastforward push. We'll continue to see problems like this, if we sync branches with shared names, across mercurial repos, which contain different histories, but we're good for now.

I was able to solve this by transplanting some changesets, and I recorded my actions for this and one other branch here.

(This is more a blog post about manual investigation+actions taken after automated emails highlighted the issue, rather than a feature of the new vcs sync process, but the emails themselves were key...)

:bhearsum filed filed bug 924024 (kill relbranches), which should help reduce the frequency of this happening.