2019-05-28 13:12:27 +03:00
|
|
|
$ setconfig extensions.treemanifest=!
|
2017-02-10 05:02:52 +03:00
|
|
|
|
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
|
2019-01-30 03:25:33 +03:00
|
|
|
> from edenscm.mercurial import extensions
|
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
|
|
|
> 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
|
2017-04-12 23:21:16 +03:00
|
|
|
$ 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)
|
2017-04-12 23:21:16 +03:00
|
|
|
$ 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
|
2017-10-17 23:05:18 +03:00
|
|
|
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
|
|
|
|
|
|
|
$ hg up
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
|
|
|
|
$ cat y
|
|
|
|
y
|
|
|
|
|
2016-10-31 23:40:33 +03:00
|
|
|
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 ..
|