sapling/tests/test-infinitepush-push-to-other.t
Thomas Orozco d6c8fef226 infinitepush: alias "default" path into "infinitepush"
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
2019-06-03 05:30:44 -07:00

109 lines
3.2 KiB
Perl

$ setconfig extensions.treemanifest=!
Setup the test
$ . "$TESTDIR/library.sh"
$ . "$TESTDIR/infinitepush/library.sh"
$ setupcommon
$ enable infinitepush pushrebase
$ cp "$HGRCPATH" "$TESTTMP/defaulthgrc"
$ hg init repo1
$ cd repo1
$ setupserver
$ cd ..
$ hg init repo2
$ cd repo2
$ setupserver
$ cd ..
$ hg init repo3
$ cd repo3
$ setupserver
$ cd ..
Check that we replicate a push
$ hg clone ssh://user@dummy/repo1 client -q
$ cp "$TESTTMP/defaulthgrc" "$HGRCPATH"
$ cat >> "$HGRCPATH" << EOF
> [paths]
> default-push=ssh://user@dummy/repo3
> infinitepush=ssh://user@dummy/repo1
> infinitepush-other=ssh://user@dummy/repo2
> [infinitepush]
> branchpattern=re:scratch/.+
> EOF
$ cd client
$ mkcommit initialcommit
$ hg push -r . --to scratch/test123 --create
pushing to ssh://user@dummy/repo1
searching for changes
remote: pushing 1 commit:
remote: 67145f466344 initialcommit
please wait while we replicate this push to an alternate repository
pushing to ssh://user@dummy/repo2
searching for changes
remote: pushing 1 commit:
remote: 67145f466344 initialcommit
$ mkcommit morecommit
$ hg push infinitepush -r . --to scratch/test123
pushing to ssh://user@dummy/repo1
searching for changes
remote: pushing 2 commits:
remote: 67145f466344 initialcommit
remote: 6b2f28e02245 morecommit
please wait while we replicate this push to an alternate repository
pushing to ssh://user@dummy/repo2
searching for changes
remote: pushing 2 commits:
remote: 67145f466344 initialcommit
remote: 6b2f28e02245 morecommit
$ mkcommit anothercommit
$ hg push default -r . --to scratch/test123
pushing to ssh://user@dummy/repo1
searching for changes
remote: pushing 3 commits:
remote: 67145f466344 initialcommit
remote: 6b2f28e02245 morecommit
remote: 17528c345014 anothercommit
please wait while we replicate this push to an alternate repository
pushing to ssh://user@dummy/repo2
searching for changes
remote: pushing 3 commits:
remote: 67145f466344 initialcommit
remote: 6b2f28e02245 morecommit
remote: 17528c345014 anothercommit
$ cd ..
Check that we do not replicate a push to the same destination
$ hg clone ssh://user@dummy/repo1 client2 -q
$ cp "$TESTTMP/defaulthgrc" "$HGRCPATH"
$ cat >> "$HGRCPATH" << EOF
> [paths]
> infinitepush-other=ssh://user@dummy/repo1
> [infinitepush]
> branchpattern=re:scratch/.+
> EOF
$ cd client2
$ mkcommit initialcommit
$ hg push -r . --to scratch/test456 --create
pushing to ssh://user@dummy/repo1
searching for changes
remote: pushing 1 commit:
remote: 67145f466344 initialcommit
$ cd ..
Check that we do not replicate a push when the destination is set
$ hg clone ssh://user@dummy/repo1 client3 -q
$ cp "$TESTTMP/defaulthgrc" "$HGRCPATH"
$ cat >> "$HGRCPATH" << EOF
> [paths]
> infinitepush-other=ssh://user@dummy/repo2
> [infinitepush]
> branchpattern=re:scratch/.+
> EOF
$ cd client3
$ mkcommit initialcommit
$ hg push ssh://user@dummy/repo3 -r . --to scratch/test789 --create
pushing to ssh://user@dummy/repo3
searching for changes
remote: pushing 1 commit:
remote: 67145f466344 initialcommit
$ cd ..