Summary:
Through Scuba, we can identify quite a few users that are doing `hg push default` for an infinitepush: https://fburl.com/scuba/6vz3ien7.
This is typically happening in repositories where the `default-push` destination is not the hg repository.
In fact, we actually prompt users to use hg push default if they try to perform a scratch push to a svn repository a few lines below!
markbt suggested we should just replicate the push in this case as well, which I think is a good idea.
Simply replicating the push in this case is not quite enough, however!
Indeed, for our infinitepushes to go to both Mercurial and Mononoke, we would have to maintain an number of consistency rules between `default`, `infinitepush`, and `infinitepush-other`:
- `default` and `infinitepush-other` must point to opposite repositories (i.e. one Mercurial, one Mononoke), to serve users using `hg push default`.
- `infinitepush` and `infinitepush-other` must point to opposite repositories, to serve users using `hg push` without a path.
This effectively means `default` and `infinitepush` must be the same, and `infinitepush-other` must be the other. We could do this with path markers, but this is getting so complicated that I don't foresee us getting it right.
At the end of the day, the root cause of this complexity stems from the fact that we're using a destination that is now effectively a read path (`default`) for infinitepush writes. I think this was perfectly valid when default meant "Mercurial, not subversion", but not so much now that we have Mononoke in the mix.
Of course, we could just update the message and ask our users to use `hg push infinitepush` instead, but this would mess with their muscle memory as well as their shell history (not to mention that `hg push default` would silently do the wrong thing).
So, this patch updates the code to use the infinitepush "write" destination for writes when that is what the user intended.
---
As a side note, note that the current behavior is actually a little broken. Indeed, if one were to do `hg push default --to scratch/$FOO` while Mononoke is serving reads, the scratch would go to Mononoke. In this scenario, the scratch push would in theory have been accepted but would have had its bookmarks discarded (at least until we support htose in Mononoke :) ).
This probably never happened in practice, however, for two reasons:
- Most users and systems that actively push scratch bookmarks are actually pushing to a specific `hg.vip` path instead of `default` (one notable exception is On Demand WWW).
- `hg push` to Mononoke for a scratch bookmark doesn't actually work if you have the pushrebase extension code loaded in some way (either by enabling the extension, or enabling an extension that uses it). See D15576199 for the details.
Reviewed By: farnz
Differential Revision: D15576545
fbshipit-source-id: c28b808632505bb8e8f4d114029f7d8c17c9749e
Summary: This updates `hg push` to replicate pushes to the `infinitepush-other` path. This ensures that we replicate pushes to scratch branches to Mononoke once we enable this mechanism.
Reviewed By: markbt
Differential Revision: D15538790
fbshipit-source-id: 0baa31f26f516cf5d2f6ec5a14d8006c912766c2
