facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-09 16:31:02 +03:00
Code Issues Projects Releases Wiki Activity
51aa41fa78
sapling/tests/test-remotenames-selective-pull.t

245 lines
7.0 KiB
Perl
Raw Normal View History

remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
Set up repos
$ cat >> $HGRCPATH << EOF
> [ui]
> ssh=python "$TESTDIR/dummyssh"
> [extensions]
remotenames: fix tests
2018-01-03 17:15:47 +03:00
> remotenames=
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
> EOF
$ hg init remoterepo
$ hg clone -q ssh://user@dummy/remoterepo localrepo
Pull master bookmark
$ cd remoterepo
$ echo a > a
$ hg add a
$ hg commit -m 'First'
$ hg book master
$ cd ../localrepo
$ hg pull
pulling from ssh://user@dummy/remoterepo
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
tests: match upstream output
2017-10-18 01:24:27 +03:00
new changesets 1449e7934ec1
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
(run 'hg update' to get a working copy)
$ hg bookmarks --remote
default/master 0:1449e7934ec1
Set up selective pull
tests: write to local hgrc A future test will need to run without selective pull enabled, so let’s not set the global config
2017-01-30 18:54:09 +03:00
$ cat >> .hg/hgrc << EOF
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
> [remotenames]
> selectivepull=True
> selectivepulldefault=master
> EOF
Create another bookmark on the remote repo
$ cd ../remoterepo
$ hg up null
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
(leaving bookmark master)
$ hg book secondbook
$ echo b >> a
$ hg add a
$ hg commit -m 'Commit secondbook points to'
Do not pull new boookmark from local repo
$ cd ../localrepo
$ hg pull
pulling from ssh://user@dummy/remoterepo
no changes found
$ hg bookmarks --remote
default/master 0:1449e7934ec1
Do not pull new bookmark even if it on the same commit as old bookmark
$ cd ../remoterepo
$ hg up -q master
$ hg book thirdbook
$ cd ../localrepo
$ hg pull
pulling from ssh://user@dummy/remoterepo
no changes found
$ hg bookmarks --remote
default/master 0:1449e7934ec1
Move master bookmark
$ cd ../remoterepo
$ hg up -q master
$ echo a >> a
$ hg commit -m 'Move master bookmark'
$ cd ../localrepo
$ hg pull
pulling from ssh://user@dummy/remoterepo
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
tests: match upstream output
2017-10-18 01:24:27 +03:00
new changesets 0238718db2b1
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
(run 'hg update' to get a working copy)
$ hg bookmarks --remote
default/master 1:0238718db2b1
Specify bookmark to pull
$ hg pull -B secondbook
pulling from ssh://user@dummy/remoterepo
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
tests: match upstream output
2017-10-18 01:24:27 +03:00
new changesets ed7a9fd254d1
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg bookmarks --remote
default/master 1:0238718db2b1
default/secondbook 2:ed7a9fd254d1
Create second remote
$ cd ..
selectivepull: fix passing `heads` argument multiple times Usually `heads` are passed using kwargs but sometimes they are passed using args (for example, during clone). In this case we set in kwargs and args and orig call fails. This patch fixes it. Also change the tests to cover this behaviour.
2017-01-30 18:53:28 +03:00
$ hg clone -q ssh://user@dummy/remoterepo secondremoterepo
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
$ cd secondremoterepo
$ hg up -q 0238718db2b1
selectivepull: fix tests There was a change upstream b2eb5bb9709893ebd015b97c06f4242b3b4c7b48 that added a warning. --force makes this warning go away.
2017-05-31 19:11:15 +03:00
$ hg book master --force
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
$ cd ..
Add second remote repo path in localrepo
$ cd localrepo
$ cat >> $HGRCPATH << EOF
> [paths]
> secondremote=ssh://user@dummy/secondremoterepo
> EOF
$ hg pull secondremote
pulling from ssh://user@dummy/secondremoterepo
no changes found
$ hg book --remote
default/master 1:0238718db2b1
default/secondbook 2:ed7a9fd254d1
secondremote/master 1:0238718db2b1
Move bookmark in second remote, pull and make sure it doesn't move in local repo
$ cd ../secondremoterepo
selectivepull: fix tests There was a change upstream b2eb5bb9709893ebd015b97c06f4242b3b4c7b48 that added a warning. --force makes this warning go away.
2017-05-31 19:11:15 +03:00
$ hg book secondbook --force
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
$ echo aaa >> a
$ hg commit -m 'Move bookmark in second remote'
$ cd ../localrepo
$ hg pull secondremote
pulling from ssh://user@dummy/secondremoterepo
no changes found
Move bookmark in first remote, pull and make sure it moves in local repo
$ cd ../remoterepo
$ hg up -q secondbook
$ echo bbb > a
$ hg commit -m 'Moves second bookmark'
$ cd ../localrepo
$ hg pull
pulling from ssh://user@dummy/remoterepo
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
tests: match upstream output
2017-10-18 01:24:27 +03:00
new changesets c47dca9795c9
remotenames: selectivepull, pull only bookmarks that are in remotenames Initial diff for the `Selective Pull` project (for details see https://www.mercurial-scm.org/wiki/SelectivePullPlan). A little bit of context. There are certain scalability issues if hg server has many bookmarks. And usually user is interested in only a small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user is interested in `remotenames.selectivepulldefault` bookmark. If user does `hg pull -B remotebook`, then user is also interested in `remotebook` (in later diffs user will be able to show interest in bookmarks by running `hg up BOOK`). There are behavior changes with remotenames.selectivepull turned on: 1 When running `hg pull` if `-B` option is not specified then remotenames file is parsed and only bookmarks for this remote are downloaded (or `master` if there are no bookmarks for this remote in remotenames file) 2 Only "interesting" bookmarks are saved in remotenames file. There were a few questions/suggestions from Sean Farley. 1 Sean suggested to add `hg pull --all` flag to override selectivepull behavior. I'll add it in the next diffs. 2 Pass a refspec as a parameter. I haven't thought about it, but we can add it later if it's necessary. 3 Use `remotenames.alias.default` instead of `remotenames.selectivepull`. But for me it seems that these two flags have different purpose. So I'm not sure why we should mix them. Test Plan: Run remotenames tests
2016-08-18 12:50:20 +03:00
(run 'hg update' to get a working copy)
$ hg bookmarks --remote
default/master 1:0238718db2b1
default/secondbook 3:c47dca9795c9
secondremote/master 1:0238718db2b1
Delete bookmark on the server
$ cd ../remoterepo
$ hg book -d secondbook
$ cd ../localrepo
$ hg pull
pulling from ssh://user@dummy/remoterepo
no changes found
$ hg bookmarks --remote
default/master 1:0238718db2b1
secondremote/master 1:0238718db2b1
remotenames: selectivepull, update to the unknown bookmark tries to pull it Part of Selective Pull project (see https://www.mercurial-scm.org/wiki/SelectivePullPlan for details). If Selective Pull is enabled, then we want to be able to check out revision even if it's not present locally, but present on remote server. If rev or node is not present locally, new request is issued to find it remotely. If it is present remotely then it's pulled. Test Plan: Run remotenames tests
2016-08-22 13:11:30 +03:00
Update to the remote bookmark
$ hg update thirdbook
`thirdbook` not found: assuming it is a remote bookmark and trying to pull it
pulling from ssh://user@dummy/remoterepo
no changes found
`thirdbook` found remotely
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg book --verbose
no bookmarks set
$ hg book --remote
default/master 1:0238718db2b1
default/thirdbook 0:1449e7934ec1
secondremote/master 1:0238718db2b1
Trying to update to unknown bookmark
$ hg update unknownbook
`unknownbook` not found: assuming it is a remote bookmark and trying to pull it
pulling from ssh://user@dummy/remoterepo
pull failed: remote bookmark unknownbook not found!
abort: unknown revision 'unknownbook'!
[255]
Update to the remote bookmark from secondremote
$ hg update secondremote/secondbook
`secondremote/secondbook` not found: assuming it is a remote bookmark and trying to pull it
pulling from ssh://user@dummy/secondremoterepo
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
tests: match upstream output
2017-10-18 01:24:27 +03:00
new changesets 0022441e80e5
remotenames: selectivepull, update to the unknown bookmark tries to pull it Part of Selective Pull project (see https://www.mercurial-scm.org/wiki/SelectivePullPlan for details). If Selective Pull is enabled, then we want to be able to check out revision even if it's not present locally, but present on remote server. If rev or node is not present locally, new request is issued to find it remotely. If it is present remotely then it's pulled. Test Plan: Run remotenames tests
2016-08-22 13:11:30 +03:00
(run 'hg update' to get a working copy)
`secondremote/secondbook` found remotely
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg book --remote
default/master 1:0238718db2b1
default/thirdbook 0:1449e7934ec1
secondremote/master 1:0238718db2b1
secondremote/secondbook 4:0022441e80e5
Update make sure revsets work
$ hg up '.^'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
selectivepull: add selectivepullenabled file 'selectivepullenabled' file is used for transition between non-selectivepull repo to selectivepull repo. It is used as indicator to whether "non-interesting" bookmarks were removed from remotenames file.
2017-01-30 18:54:09 +03:00
Make another clone with selectivepull disabled
$ hg clone -q ssh://user@dummy/remoterepo localrepo2
$ cd localrepo2
$ hg book --remote
default/master 2:0238718db2b1
default/thirdbook 0:1449e7934ec1
Enable selectivepull and make a pull. Make sure only master bookmark is left
$ cat >> .hg/hgrc << EOF
> [remotenames]
> selectivepull=True
> selectivepulldefault=master
> EOF
$ hg pull -q
$ hg book --remote
default/master 2:0238718db2b1
Temporarily disable selectivepull, pull, enable it again and pull again.
Make sure only master bookmark is present
$ hg pull --config remotenames.selectivepull=False -q
$ hg book --remote
default/master 2:0238718db2b1
default/thirdbook 0:1449e7934ec1
$ hg pull -q
$ hg book --remote
default/master 2:0238718db2b1
selectivepull: support list of default bookmarks The addition is that we now support list of default bookmarks, instead of a single default bookmark (the previous behavior).
2017-01-30 18:54:09 +03:00
Set two bookmarks in selectivepulldefault, make sure both of them were pulled
$ cat >> .hg/hgrc << EOF
> [remotenames]
> selectivepulldefault=master,thirdbook
> EOF
$ rm .hg/selectivepullenabled
$ hg pull -q
$ hg book --remote
default/master 2:0238718db2b1
default/thirdbook 0:1449e7934ec1
Reference in New Issue Copy Permalink