I think if it was not for the convoluted Revlog [1] format (which makes it impossible to do a clean-room reimplementation of Mercurial Core), we could see a bit more of adoption by having third-party libraries to interface with Hg repositories. It _might_ have been one of the reasons Git, not Mercurial, was added to TFS [2].
>if it was not for the convoluted Revlog [1] format (which makes it impossible to do a clean-room reimplementation of Mercurial Core), we could see a bit more of adoption
Alternatively, we could see a bit more adoption if it were available under a more permissive license than the GPL.
You can theoretically reimplement Git Core by only referencing the documentation, which, according to some sources, does not "infect" the new code with GPL.
could you not have replaced git with hg above, and the argument still holds? Revlog's format itself isn't under copyright (and i doubt it exists, but only with a patent can you stop a _format_ spec from being used). If you wrote a parser for the revlog format, you aren't "infected".
Also, hg plugins are much easier to write (being in python and all), than messing around with git's internals imho (ala, facebook's modification to hg to make it massively scalable https://code.facebook.com/posts/218678814984400/scaling-merc..., which would've been almost impossible in git).
It's not realistically possible to write a Revlog parser by only using whatever documentation is available; you _will_ have to reference the Hg source code, which will turn your project into "derived work".
Alternatively, we could see a bit more adoption if it were available under a more permissive license than the GPL.