--
You received this message because you are subscribed to the Google Groups "mozilla-code-review" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-code-review+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On March 14, 2014 at 1:04:47 AM, Gregory Szorc (g...@mozilla.com) wrote:
On 3/12/14, 6:33 PM, Ehsan Akhgari wrote:
> (Sorry this email was stuck in the moderation queue, I've tried to set
> this group to accept posts from non-subscribers but it doesn't seem to
> work...)
>
> I have already asked Taras about this and he has said that we're working
> on things which will give us hg repos with good performance in general.
>
> All I know about the scaling problems here is about hg, do you have
> information on similar scaling problems in git?
An organization I talked to experienced this multi-headed scaling
problem with both Mercurial and Git. Mozilla will likely never throw as
much hardware at the problem as this other organization. This
organization decided it was better to avoid solving the problem (if it's
even possible) and scale with bundles
I can’t say anything about Mercurial, but having this problem with Git is really weird.
Git’s heads are basically branches - they are created and removed during project lifetime.
Unless you have thousands of active branches, you should be fine with Git.
As soon as the branch is removed, it’s head is gone and should not affect performance at all.
Here’s a nice writeup: http://git-scm.com/book/en/Git-Internals-Git-References
AFAIK Review Board won’t cache those diffs at the moment.
But at the same time, RB doesn’t care about the concept of “head” - all it needs is the changeset.
Again, I’m not sure how relevant this is for Mercurial, but just having the changeset somewhere in DAG should be enough for RB to work - we don’t need a separate head for each of those changesets.
Maybe we can “garbage collect” the heads in some way that leaves changesets in DAG?
Another benefit of bundles just occurred to me: authentication. Our SSH
key management doesn't (currently) scale. It's much easier to post a
bundle through a Persona (or similar) authenticated web service than to
establish an SSH public key at Mozilla. Hopefully we make SSH key
management self-service some day...
If we use SSH keys for push access anyway, I think it’s more beneficial in the long term to figure out the key management.
Thanks,
George