sapling/tests/test-fb-hgext-remotefilelog-pull-noshallow.t

78 lines
2.1 KiB
Perl
Raw Normal View History

$ PYTHONPATH=$TESTDIR/..:$PYTHONPATH
$ export PYTHONPATH
fix crash in "hg pull" when remotefilelog not enabled Summary: 764cd9916c94 recently introduced code that was unconditionally checking the repo.includepattern and repo.excludepattern attributes on a local repository without first checking if this is a shallow repository. These attributes only exist on shallow repositories, causing "hg pull" to crash on non-shallow repositories. This crash wouldn't happen in simple circumstances, since the remotefilelog extension only gets fully set up once a shallow repository object has been created, however when using chg you can end up with scenarios where a non-shallow repository is used in the same hg process after a shallow one. This refactors the code to now store the local repository object on the remote peer rather than trying to store the individual shallow, includepattern, and excludepattern attributes. Overall this code does still feel a bit janky to me -- the rest of the peer API is independent of the local repository, but the _callstream() wrapper cares about the local repository being referenced. It seems like we should ideally redesign the APIs so that _callstream() receives the local repository data as an argument (or we should make the peer <--> local repository assocation more formal and explicit if think it's better to force an association here). Test Plan: Added a new test which triggered the crash, but passes with these changes. Reviewers: ttung, mitrandir, durham Reviewed By: durham Subscribers: net-systems-diffs@, yogeshwer Differential Revision: https://phabricator.intern.facebook.com/D3756493 Tasks: 12823586 Signature: t1:3756493:1471971600:9666e9c31bf59070c3ace0821d47d322671eb5b1
2016-08-24 00:14:42 +03:00
$ . "$TESTDIR/library.sh"
Set up an extension to make sure remotefilelog clientsetup() runs
unconditionally even if we have never used a local shallow repo.
This mimics behavior when using remotefilelog with chg. clientsetup() can be
triggered due to a shallow repo, and then the code can later interact with
non-shallow repositories.
$ cat > setupremotefilelog.py << EOF
> from mercurial import extensions
> def extsetup(ui):
> remotefilelog = extensions.find('remotefilelog')
> remotefilelog.onetimeclientsetup(ui)
> EOF
Set up the master repository to pull from.
$ hginit master
$ cd master
$ cat >> .hg/hgrc <<EOF
> [remotefilelog]
> server=True
> EOF
$ echo x > x
$ hg commit -qAm x
$ cd ..
$ hg clone ssh://user@dummy/master child -q
We should see the remotefilelog capability here, which advertises that
the server supports our custom getfiles method.
$ cd master
$ echo 'hello' | hg -R . serve --stdio
fix crash in "hg pull" when remotefilelog not enabled Summary: 764cd9916c94 recently introduced code that was unconditionally checking the repo.includepattern and repo.excludepattern attributes on a local repository without first checking if this is a shallow repository. These attributes only exist on shallow repositories, causing "hg pull" to crash on non-shallow repositories. This crash wouldn't happen in simple circumstances, since the remotefilelog extension only gets fully set up once a shallow repository object has been created, however when using chg you can end up with scenarios where a non-shallow repository is used in the same hg process after a shallow one. This refactors the code to now store the local repository object on the remote peer rather than trying to store the individual shallow, includepattern, and excludepattern attributes. Overall this code does still feel a bit janky to me -- the rest of the peer API is independent of the local repository, but the _callstream() wrapper cares about the local repository being referenced. It seems like we should ideally redesign the APIs so that _callstream() receives the local repository data as an argument (or we should make the peer <--> local repository assocation more formal and explicit if think it's better to force an association here). Test Plan: Added a new test which triggered the crash, but passes with these changes. Reviewers: ttung, mitrandir, durham Reviewed By: durham Subscribers: net-systems-diffs@, yogeshwer Differential Revision: https://phabricator.intern.facebook.com/D3756493 Tasks: 12823586 Signature: t1:3756493:1471971600:9666e9c31bf59070c3ace0821d47d322671eb5b1
2016-08-24 00:14:42 +03:00
* (glob)
capabilities: lookup * remotefilelog getflogheads getfile (glob)
$ echo 'capabilities' | hg -R . serve --stdio ; echo
fix crash in "hg pull" when remotefilelog not enabled Summary: 764cd9916c94 recently introduced code that was unconditionally checking the repo.includepattern and repo.excludepattern attributes on a local repository without first checking if this is a shallow repository. These attributes only exist on shallow repositories, causing "hg pull" to crash on non-shallow repositories. This crash wouldn't happen in simple circumstances, since the remotefilelog extension only gets fully set up once a shallow repository object has been created, however when using chg you can end up with scenarios where a non-shallow repository is used in the same hg process after a shallow one. This refactors the code to now store the local repository object on the remote peer rather than trying to store the individual shallow, includepattern, and excludepattern attributes. Overall this code does still feel a bit janky to me -- the rest of the peer API is independent of the local repository, but the _callstream() wrapper cares about the local repository being referenced. It seems like we should ideally redesign the APIs so that _callstream() receives the local repository data as an argument (or we should make the peer <--> local repository assocation more formal and explicit if think it's better to force an association here). Test Plan: Added a new test which triggered the crash, but passes with these changes. Reviewers: ttung, mitrandir, durham Reviewed By: durham Subscribers: net-systems-diffs@, yogeshwer Differential Revision: https://phabricator.intern.facebook.com/D3756493 Tasks: 12823586 Signature: t1:3756493:1471971600:9666e9c31bf59070c3ace0821d47d322671eb5b1
2016-08-24 00:14:42 +03:00
* (glob)
* remotefilelog getflogheads getfile (glob)
Pull to the child repository. Use our custom setupremotefilelog extension
to ensure that remotefilelog.onetimeclientsetup() gets triggered. (Without
using chg it normally would not be run in this case since the local repository
is not shallow.)
$ echo y > y
$ hg commit -qAm y
$ cd ../child
$ hg pull --config extensions.setuprfl=$TESTTMP/setupremotefilelog.py
pulling from ssh://user@dummy/master
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets d34c38483be9
fix crash in "hg pull" when remotefilelog not enabled Summary: 764cd9916c94 recently introduced code that was unconditionally checking the repo.includepattern and repo.excludepattern attributes on a local repository without first checking if this is a shallow repository. These attributes only exist on shallow repositories, causing "hg pull" to crash on non-shallow repositories. This crash wouldn't happen in simple circumstances, since the remotefilelog extension only gets fully set up once a shallow repository object has been created, however when using chg you can end up with scenarios where a non-shallow repository is used in the same hg process after a shallow one. This refactors the code to now store the local repository object on the remote peer rather than trying to store the individual shallow, includepattern, and excludepattern attributes. Overall this code does still feel a bit janky to me -- the rest of the peer API is independent of the local repository, but the _callstream() wrapper cares about the local repository being referenced. It seems like we should ideally redesign the APIs so that _callstream() receives the local repository data as an argument (or we should make the peer <--> local repository assocation more formal and explicit if think it's better to force an association here). Test Plan: Added a new test which triggered the crash, but passes with these changes. Reviewers: ttung, mitrandir, durham Reviewed By: durham Subscribers: net-systems-diffs@, yogeshwer Differential Revision: https://phabricator.intern.facebook.com/D3756493 Tasks: 12823586 Signature: t1:3756493:1471971600:9666e9c31bf59070c3ace0821d47d322671eb5b1
2016-08-24 00:14:42 +03:00
(run 'hg update' to get a working copy)
$ hg up
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat y
y
Test that bundle works in a non-remotefilelog repo w/ remotefilelog loaded
$ echo y >> y
$ hg commit -qAm "modify y"
$ hg bundle --base ".^" --rev . mybundle.hg --config extensions.setuprfl=$TESTTMP/setupremotefilelog.py
1 changesets found
fix crash in "hg pull" when remotefilelog not enabled Summary: 764cd9916c94 recently introduced code that was unconditionally checking the repo.includepattern and repo.excludepattern attributes on a local repository without first checking if this is a shallow repository. These attributes only exist on shallow repositories, causing "hg pull" to crash on non-shallow repositories. This crash wouldn't happen in simple circumstances, since the remotefilelog extension only gets fully set up once a shallow repository object has been created, however when using chg you can end up with scenarios where a non-shallow repository is used in the same hg process after a shallow one. This refactors the code to now store the local repository object on the remote peer rather than trying to store the individual shallow, includepattern, and excludepattern attributes. Overall this code does still feel a bit janky to me -- the rest of the peer API is independent of the local repository, but the _callstream() wrapper cares about the local repository being referenced. It seems like we should ideally redesign the APIs so that _callstream() receives the local repository data as an argument (or we should make the peer <--> local repository assocation more formal and explicit if think it's better to force an association here). Test Plan: Added a new test which triggered the crash, but passes with these changes. Reviewers: ttung, mitrandir, durham Reviewed By: durham Subscribers: net-systems-diffs@, yogeshwer Differential Revision: https://phabricator.intern.facebook.com/D3756493 Tasks: 12823586 Signature: t1:3756493:1471971600:9666e9c31bf59070c3ace0821d47d322671eb5b1
2016-08-24 00:14:42 +03:00
$ cd ..