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

Keep in mind that narrowhg is extremely experimental!

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

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

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

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

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.

One possibility would be to have

#else #error #endif

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

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

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

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.

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

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.

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!

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