Mathiasdm's comments

On: The GMP library's repository is under attack by a single GitHub user

[Mathiasdm]

Mercurial clones can be cached quite easily with 'clonebundles', a Mercurial feature that allows redirecting a clone to instead download a single 'bundle' (which could come from a different server or set of servers).

See https://wiki.mercurial-scm.org/ClonebundlesExtension

On: Mercurial 4.0 Sprint Notes

[Mathiasdm]

Keep in mind that narrowhg is extremely experimental!

On: Mercurial 4.0 Sprint Notes

[Mathiasdm]

What version of Mercurial were you using? Additionally, was your repository very branchy? Were your pulls stuck for a very long time on 'adding manifests'?

It's possible that your slow pulls were due to the initial storage format being inefficient for very branchy repositories. I've documented migrating to generaldelta to solve this here: https://book.mercurial-scm.org/read/scaling.html#scaling-rep...

Additionally, using the 'clonebundles' feature, it's possible to speed up your initial clone by a huge amount (making it way faster than non-clonebundles Mercurial or Git): https://book.mercurial-scm.org/read/scaling.html#improving-s...

Of course, this is too late for you, I guess...

On: Show HN: BitKeeper – Enterprise-ready version control, now open-source

[Mathiasdm]

Mercurial has had 'largefiles' since Mercurial 2.0, 5 years ago.

[stonemetal → Mathiasdm]

While it is better than git at working with large files, the large file extension doesn't solve the problem 100%.

On: Storing large binary files in Git repositories (2015)

[Mathiasdm]

For some added context about handling binaries in Mercurial, see the (in development) Mercurial book: http://hgbook.org/read/scaling.html#handle-large-binaries-wi...

On: Almost Everything We Do Will Be Open

[Mathiasdm]

Mercurial has had support for large binary files using the 'largefiles' extension for several years now.

On: On Monolithic Repositories

[Mathiasdm]

I helped set up such a system for a few hundred developers. We had an 'automated Linus Torvalds', which did the merge, and aborted whenever a file was changed on both sides of the merge.

In the good case (almost every time), there were no conflicts, and the merge went fine (we had unittests, builds and regression tests as extra checks in our CI system).

In the bad case, the developer request was rejected and the developer was told to rebase or merge his code on his own, so the merge issues would be handled.

On: Porting the Unity Editor to Linux: Stuff I Wish We’d Done Then

[Mathiasdm]

One possibility would be to have

#else #error #endif

If you work this way, you immediately know where to change your code.

On: Mercurial: Onward and upward

[Mathiasdm]

I'm guessing it depends from project to project? There are several Google developers contributing to Mercurial.

[cdibona → Mathiasdm]

If you look at development at Google, you'll see most people on a perforce derived repo system , then groups like Android, chrome, Etc on git, then basically very few teams using Mercurial.

We do have some hg contributors like augie, but we have way more git contributors, includes git project Lead Junio.

On: Unorthodocs: Abandon Your DVCS and Return to Sanity

[Mathiasdm]

One alternative to consider is Mercurial (which command-line wise is more similar to Subversion) with subrepos (which have better usability): http://www.selenic.com/hg/help/subrepos

[chaz72 → Mathiasdm]

Thanks, I will look into this.