On 9/19/13 9:31 PM, Blair McBride wrote:
Ohai!
I have numerous copies of mozilla-central (and other repos) for various
purposes - spread around physical boxes and VMs. Some of them I use
regularly and update regularly, others not-regularly. I've been thinking
about the amount of time and bandwidth I waste updating them all from a
remote server (hg.mozilla.org, github, etc). I suspect I'm not alone in
this.
So, I was thinking of setting up a local mirror of mozilla-central (and
other repos) - and update my development repos from the local mirror.
Obviously, I'd like to automatically keep the mirror up to date, but
without hammering the remote server. I was thinking regularly scheduled
updates from the remote, as well as on-demand updates whenever I pull
from the local mirror if the last scheduled update was greater than X
hours ago.
Has anyone setup this type of system before? Or know of any tools that
already handle this? It'd be nice to save some time by working from
previous art, as well as document the process for others.
In terms of bandwidth, our model of separate repositories for each
"branch" is horribly inefficient using the standard 1 clone per repo
model. Over time, each repo merged into m-c nears 100% redundancy with m-c.
A solution to this is a unified repository with the changesets for all
the repos. That way, when you do `hg pull`, you don't pull the changeset
(technically the file content) once for every repository. My "mozext"
Mercurial extension [1] makes this painless:
$ hg pull releases # pulls all the major "release" branches
$ hg pull inbound fx-team # pulls inbound and fx-team
$ hg up fx-team/default # updates to fx-team "tip"
$ hg pushtree inbound # push the current "tip" to fx-team
You can also use the "share" Mercurial extension for sharing changeset
content across checkouts. Although, mq doesn't play nice with it (mq
works on a model of stripping "committed" changesets, and that's not
compatible with sharing a storage backend).
On the subject of mq, it also doesn't play nice with automatic pulling
of changesets. If you have applied mq patches and pull, when you qpop,
Mercurial will bundle all the changesets "after" the mq changesets,
strip them, pop the mq changesets, and reapply the bundled changesets to
the repo. Horribly inefficient. I can't wait for mq to be replaced by
changeset evolution [2].
If you care about bandwidth and latency, I'd set up a unified repo
without a working copy (hg clone -U) and a CRON that pulls changesets
every minute or two. Then, have your working repositories pull from this
mirror. Push directly to hg.mozilla.org.
[1] https://hg.mozilla.org/users/gszorc_mozilla.com/hgext-gecko-dev
[2] http://mercurial.selenic.com/wiki/ChangesetEvolution
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
