Hacker News: Mathiasdm

New comment by Mathiasdm in "The GMP library's repository is under attack by a single GitHub user"

Mathiasdm — Mon, 19 Jun 2023 05:43:52 +0000

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

New comment by Mathiasdm in "Mercurial 4.0 Sprint Notes"

Mathiasdm — Wed, 19 Oct 2016 06:42:36 +0000

Keep in mind that narrowhg is extremely experimental!

New comment by Mathiasdm in "Mercurial 4.0 Sprint Notes"

Mathiasdm — Wed, 19 Oct 2016 04:41:25 +0000

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...

New comment by Mathiasdm in "Show HN: BitKeeper – Enterprise-ready version control, now open-source"

Mathiasdm — Wed, 11 May 2016 04:59:26 +0000

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

Mercurial 3.7 and 3.8: performance all the way

Mathiasdm — Tue, 03 May 2016 15:43:22 +0000

Article URL: http://mathiasdm.com/2016/05/03/mercurial-3-7-and-3-8/

Comments URL: https://news.ycombinator.com/item?id=11621627

Points: 5

# Comments: 0

New comment by Mathiasdm in "Storing large binary files in Git repositories (2015)"

Mathiasdm — Tue, 08 Mar 2016 16:10:16 +0000

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...

New comment by Mathiasdm in "Almost Everything We Do Will Be Open"

Mathiasdm — Fri, 07 Aug 2015 13:24:15 +0000

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

New comment by Mathiasdm in "On Monolithic Repositories"

Mathiasdm — Wed, 05 Aug 2015 13:17:42 +0000

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.

New comment by Mathiasdm in "Porting the Unity Editor to Linux: Stuff I Wish We’d Done Then"

Mathiasdm — Mon, 29 Jun 2015 07:08:24 +0000

One possibility would be to have

#else #error #endif

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

New comment by Mathiasdm in "Mercurial: Onward and upward"

Mathiasdm — Thu, 30 Apr 2015 18:32:04 +0000

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

New comment by Mathiasdm in "Unorthodocs: Abandon Your DVCS and Return to Sanity"

Mathiasdm — Mon, 02 Mar 2015 10:20:58 +0000

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

New comment by Mathiasdm in "Mastering Git submodules"

Mathiasdm — Fri, 20 Feb 2015 10:56:59 +0000

Interesting overview!

Some of this caveats are kinda surprising for me, coming from a Mercurial background:

* Every time you add a submodule, change its remote’s URL, or change the referenced commit for it, you demand a manual update by every collaborator. Forgetting this explicit update can result in silent regressions of the submodule’s referenced commit. -- This is something handled automatically in Mercurial. Is there any reason why the same behaviour is not used in Git?

* Commands such as status and diff display precious little info about submodules by default. -- This should be possible to implement, no? It's also something that's available in Mercurial (using the --subrepos flag), and it's a huge boost to usability.

New comment by Mathiasdm in "Gitless: experimental version control system"

Mathiasdm — Mon, 09 Feb 2015 12:06:51 +0000

I believe this was a step in that direction: https://bitbucket.org/durin42/hgit

New comment by Mathiasdm in "Gitless: experimental version control system"

Mathiasdm — Mon, 09 Feb 2015 12:05:39 +0000

I wish Git would have used a different name than 'branch'. It's completely at odds with branches in any other version control system and only adds confusion for people switching to/from Git. Mercurial uses the term 'bookmarks' for Git-style branches, I feel that would have been a much better choice.

New comment by Mathiasdm in "Ask HN: Should I drop school?"

Mathiasdm — Wed, 01 Oct 2014 10:20:34 +0000

Make an appointment and try to talk to your teachers in person. Maybe they can guide you in the right direction, give you some pointers on what projects are suitable as a graduation work.

Don't quit!

New comment by Mathiasdm in "Can We Trust the Libraries We Use?"

Mathiasdm — Mon, 11 Aug 2014 15:44:20 +0000

__attribute__((unused)) indeed would be the best option when using gcc. I believe when using C++11, this can be replaced by [[gnu::unused]].

Another one that I've seen quite often is casting to void.

Ask HN: Any interest in build speed improvements?

Mathiasdm — Fri, 25 Jul 2014 00:22:04 +0000

Article URL: http://mathiasdm.com/2014/07/24/arriba-a-new-solution-for-build-speed-improvement/

Comments URL: https://news.ycombinator.com/item?id=8083154

Points: 2

# Comments: 0