2019-12-10 02:24:31 +03:00
|
|
|
#chg-compatible
|
|
|
|
|
2020-01-20 13:42:49 +03:00
|
|
|
$ disable treemanifest
|
2019-05-30 18:29:57 +03:00
|
|
|
|
|
|
|
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]
|
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 15:23:36 +03:00
|
|
|
> default-push=ssh://user@dummy/repo3
|
|
|
|
> infinitepush=ssh://user@dummy/repo1
|
2019-05-30 18:29:57 +03:00
|
|
|
> 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
|
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 15:23:36 +03:00
|
|
|
$ 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
|
2019-05-30 18:29:57 +03:00
|
|
|
$ 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
|
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 15:23:36 +03:00
|
|
|
$ hg push -r . --to scratch/test456 --create
|
2019-05-30 18:29:57 +03:00
|
|
|
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
|
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 15:23:36 +03:00
|
|
|
$ hg push ssh://user@dummy/repo3 -r . --to scratch/test789 --create
|
2019-05-30 18:29:57 +03:00
|
|
|
pushing to ssh://user@dummy/repo3
|
|
|
|
searching for changes
|
|
|
|
remote: pushing 1 commit:
|
|
|
|
remote: 67145f466344 initialcommit
|
|
|
|
$ cd ..
|