Encouraging best practices through server communication

Gregory Szorc gregory.szorc at gmail.com
Tue Dec 10 04:41:50 CST 2013

 From my experience observing dozens of developers work on a large 
Mercurial project (Firefox), it's increasingly apparent to me that a 
large chunk of Mercurial users are failing to harness some of the basic 
features of Mercurial, much less adopt some of the "advanced" practices 
we prescribe for Firefox development (including a slew of custom 

While I think the out-of-the-box Mercurial experience could be more 
proactive about certain features (e.g. more UX only extensions like 
color and pager enabled by default, "advertisements" about related 
commands and functionality, etc), there are scenarios where vanilla 
Mercurial alone doesn't know about best practices. For example, let's 
say you have written a custom Mercurial extension to make interacting 
with your repo better. It provides custom hooks to ensure linting before 
push, etc. You /really/ want people to install it because it's so 
awesome and makes your code better. Unfortunately, getting the message 
out through traditional channels is hard (say it's a large, distributed, 
open source project). What other methods are available to us?

I put together a "best practices" Mercurial extension [1] to try to 
solve this problem. Essentially, the server detects when clients don't 
have this extension installed and alerts them to install it. When a 
client has the extension installed, it asks the server to describe its 
recommended best practices. The server sends down some metadata (minimum 
client version, what extensions to have installed, etc) and the client 
self-checks its conformance and notifies/prompts about "violations." The 
client can even auto-install extensions from the repo URLs specified by 
the server! Effectively, the server prescribes a set of best practices 
for interacting with it and the client helps the user achieve that state.

While the extension isn't finished and has yet to be deployed outside of 
testing, I thought I'd share it with this list for a few reasons. First, 
I think people may find it interesting. Second, I have technical 
concerns/questions about the implementation. There are a number of 
aspects of the implementation that feel too hacky to me. There is also 
functionality not possible with Mercurial today (mainly due to the wire 
protocol design). I'd like to have a discussion about supporting these 
use cases in a future Mercurial release. Notably:

* Client doesn't self-advertise capabilities like servers do. It would 
be cool if servers could proactively sniff for missing capabilities and 
be like "upgrade your Mercurial install!"

* Passing messages for user display from server to client is not well 
supported. Only some commands have their output sent to the client. I 
would like a dedicated "band" in the protocol for transporting messages 
back to clients for *any* command. I think allowing servers to 
"advertise" message of the day or such on pull could be very useful.

* Possibly a superset of the above - it's not possible to exchange 
arbitrary metadata as part of client-server communication. My extension 
would be much, much easier if every command request and response could 
have arbitrary (key-value?) metadata attached to it.

Is there any interesting in pursuing these features? Do people think my 
extension has wheels?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=941856

Gregory Szorc
gregory.szorc at gmail.com

More information about the Mercurial mailing list