Re: Scaling Mercurial at Facebook

["Perry E. Metzger" <perry%piermont.com@localhost>]

On Sun, 19 Jan 2014 22:02:24 +0100 Martin Husemann
<martin%duskware.de@localhost> wrote:
> On Sun, Jan 19, 2014 at 10:35:59AM -0500, Perry E. Metzger wrote:
> > I think that might lead to some self-deception. It is not
> > possible to plan such a thing perfectly.
> 
> It is not about a perfect plan, but folks stay at the "I demand to
> convert pkgsrc to git and somebody else (tm) to solve all the hard
> problems this causes" level.

That is clearly unreasonable, of course, and I think we're in
agreement there.

> And the hard problems here includes thinking about authentication,
> key distribution, changes in workflow, changes to other project
> machines and what have you.

Absolutely. That's why I favor an experiment using a small portion of
the repository -- that will shake out issues that one would not have
anticipated in advance.

> The possible options should be clear
> (or easy to find out) for someone already successfully using the
> target SCM in other contexts, so it seems only fair to put the onus
> of creating a rough plan on the proponents of each system.

Thinking aloud here to actually discuss the substantive options:

For git in particular, the overall centralized repository model need
not change -- the project would maintain the One True Repo on a
project-run machine. However, we would expect that developers with
commit privs would do their commits against their local copies of the
repository and then push these changes up to the central repo, while
those without commit privs would do things like mailing in patch
sets in the git format or submitting them with bug system tickets.
Email messages would probably be sent out whenever the central repo
was updated, as happens now.

Exposing the git wire protocol itself is probably not a good idea, so
the authentication and access system used right now, that is, ssh as
the sole point of entry with the commands that could be executed on
the repository machine size restricted, seems just fine. One would
then want pushes to trigger simultaneous updates to the world-facing
copy on "anongit" or whatever the DNS label would be called -- that
machine would probably expose the git wire protocol.

So, all in all, not much change over the way things happen now.
Again, though, no plan survives contact with the real world, and
doubtless some significant issues will appear during the course of
experimentation.

Thoughts?

-- 
Perry E. Metzger                perry%piermont.com@localhost