
Mononoke – A Mercurial source control server designed to support large monorepos - guifortaine
https://github.com/facebookexperimental/mononoke
======
ethomson
Git Community PM at Microsoft here: I'm very impressed by Facebook's source
control team in general (and Mononoke in particular). They're doing a lot of
interesting things, and they've developed a very opinionated workflow about
working in their monorepo that is very helpful for their workflows.

Another comment suggests that there's "fierce competition" in the version
control space. In fact, I think that there's fierce collaboration in the
version control space! Durham Goode from their team gave an interesting talk
at Git Merge 2017 about how they're using Hg and some of the interesting user-
experience tools that they've built on top of it:
[https://m.youtube.com/watch?list=PL0lo9MOBetEGRAJzoTCdco_fOK...](https://m.youtube.com/watch?list=PL0lo9MOBetEGRAJzoTCdco_fOKDfhqaOY&v=gOVD-
DrUpwQ)

I don't personally prefer Mercurial (I like Git, as you might have guessed),
but I think that there's some opportunities to learn from their user
experiences and perhaps add or improve some high-level Git commands.

~~~
rattray
While you're here, can you say anything about when beta users outside of
MSFT/GH might be able to try GVFS?

Do you think GVFS will also be able to support "thousands of commits an hour"?
(It prominently claims to support "millions of files").

~~~
stolee
Your second question about "thousands of commits an hour" is actually a server
scale question, as opposed to a GVFS question. The main difference is that
GVFS is primarily client software plus some extra server protocols that a
server must support.

I find the "thousands of commits an hour" measurement to be conflating
multiple things. I'll split out my expectations in our experience with the
Windows repo.

The Windows repository is hosted in VSTS and handles over 4,000 developers
doing their daily work. This includes an average of 3,000+ pushes per day via
the Git protocol. Each push may include multiple commits. At least 2,300+ pull
requests are completed per day, which creates a new merge commit each time.
Also, the build machines run daily and kick off a push as their first action
to update a version number. This creates 250+ parallel pushes within a 10
second window, so a spike of concurrent pushes are supported by VSTS.

~~~
rattray
Thanks, that's very helpful color!

(Plus, a nice ad for VSTS – well done).

------
kyrra
Btw, mercurial has a longer term goal to rewrite parts of hg in rust.

[https://www.mercurial-scm.org/wiki/OxidationPlan](https://www.mercurial-
scm.org/wiki/OxidationPlan)

------
jlebar
There's some irony that this lives on...github.

/git evangelism strike force

~~~
gmueckl
They really should have put it on Bitbucket. Hosting code for a VCS publicly
and using the most fiercely competing system for it just sends the wrong
message. How did nobody catch this?

~~~
ethomson
I think that the message it sends is that we collaborate with each other -
Mercurial and Git, Facebook's Mononoke and Microsoft's GVFS. And since GitHub
is _the_ place where open source software development happens, that's where
this is hosted.

We're not enemies. We're not competing. We're trying to make developers lives
better, and there are a number of techniques that can work, and a number of
tools that can help them.

~~~
gmueckl
Competition does not stop when you don't want to see it. It exists already by
the virtue of having multiple similar products in the first place. You can't
wish that away. The world doesn't work that way.

~~~
ethomson
Well, then I wish Mercurial nothing but luck in winning the lucrative free
version control client market.

Edit: sarcasm aside, you're right in saying that there is competition here.
And competition is healthy, it's what drives us to solve problems in different
ways and _allows_ us to collaborate. But to suggest that we shouldn't use each
others technologies feels short sighted and like the _wrong_ kind of
competition.

~~~
gmueckl
Github is proof that the market is lucrative. There is no sarcasm here.

You have to be careful what you use other technology for. If you don't show
that you're relying on your own product when you clearly have a chance to do
so, you immediately lose trust. First impressions matter a ton there.

~~~
rattray
Github isn't git; if hg takes off, github (the company) can just add support
for it.

SCM hosting is very different than SCM software; the latter is usually... not
lucrative.

Eg; I'm sure MSFT hopes to make money from their GVFS effort, but not by
selling it – simply by using it as a marketing tool to establish credibility
(eg; for Team Foundation Server and other developer products).

Even if nobody _used_ GVFS, it could still be a profitable project for MSFT if
it made everyone think MSFT an expert in source control. (To be clear, I love
this incentive structure, and it's working on me – my respect for Microsoft is
growing, thanks in part to GVFS).

------
wodenokoto
Most people might know the name from the 1997 anime [0], not really know what
the word means, but recognize the "mono" part as "singular". But really, it
means monster [1]

[0]
[https://en.wikipedia.org/wiki/Princess_Mononoke](https://en.wikipedia.org/wiki/Princess_Mononoke)
[1]
[http://jisho.org/word/%E7%89%A9%E3%81%AE%E6%80%AA](http://jisho.org/word/%E7%89%A9%E3%81%AE%E6%80%AA)

~~~
jsgf
Mono-repo -> we're focusing our efforts on few large repos

Mono-tone -> The first cryptographic Merkle-tree distributed source control
system, which was a large influence on both Git and Mercurial.

Monotone was written by Graydon Hoare, who later went on to design Rust (I
think he was actually designing proto-Rust at the time), so the reference to
Monotone is to both Mononoke's function and implementation.

------
mikevm
Why did Facebook choose Mercurial over Git?

~~~
michel-slm
from a previous blog post:

"Our engineers were comfortable with Git and we preferred to stay with a
familiar tool, so we took a long, hard look at improving it to work at scale.
After much deliberation, we concluded that Git's internals would be difficult
to work with for an ambitious scaling project."

[https://code.facebook.com/posts/218678814984400/scaling-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

~~~
sanxiyn
Note that Microsoft arrived at the opposite conclusion and wrote GVFS:
[https://github.com/Microsoft/GVFS](https://github.com/Microsoft/GVFS)

~~~
krupan
Reading that it sounds like they reached the same conclusion, that they didn't
want to mess with git's internals. They wrote a filesystem to run underneath
git.

~~~
daemin
Hearing from friends that work there, the RTT for the underlying filesystem
adds quite a lot of time for daily operations, especially if they are not
working on the west coast of the USA. It was said a pull takes 45 minutes.

This leads me to believe that to handle large repos and files within a tool
like git, its internals should be changed a bit so that there's not as many
file accesses that need to be done (fstat, read, write). Also for certain
operations to be batched together to better hide the latency involved in
global communications.

~~~
alexeiz
If you're working with a Git repo on a remote filesystem, you're doing it
wrong. Git is not designed for remote filesystems. It relies on certain file
operations to be extremely fast. So Git works best with local filesystems.
With Git, you want to clone the entire repository locally and work with it
locally. That's the idea behind the distributed version control: every
committer has the entire copy of the repository. With a remote filesystem
you're effectively centralizing your repository.

~~~
daemin
Yeah, the git metadata is on a remote file server, that's the entire point of
the Microsoft file system extensions for running a huge git monorepo. The code
and assets you are working on is local, but the history and other metadata
elements are stored remote and lazy loaded.

So if you're remote file server is relatively close it doesn't matter too much
and the lag is not noticeable, but if it's across the country or across the
world...

