Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:31:23 +0100] rev 31253
vfs: use 'vfs' module directly in 'hgext.mq'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 14:49:50 +0100] rev 31252
vfs: use 'vfs' module directly in 'mercurial.unionrepo'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 14:49:01 +0100] rev 31251
vfs: use 'vfs' module directly in 'mercurial.statichttprepo'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 14:47:03 +0100] rev 31250
vfs: use 'vfs' module directly in 'mercurial.bundlerepo'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:31:07 +0100] rev 31249
vfs: use 'vfs' module directly in 'mercurial.debugcommand'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:58 +0100] rev 31248
vfs: use 'vfs' module directly in 'mercurial.simplemerge'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:47 +0100] rev 31247
vfs: use 'vfs' module directly in 'mercurial.cmdutil'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:38 +0100] rev 31246
vfs: use 'vfs' module directly in 'mercurial.subrepo'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:28 +0100] rev 31245
vfs: use 'vfs' module directly in 'mercurial.archival'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:10 +0100] rev 31244
vfs: use 'vfs' module directly in 'mercurial.store'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:29:59 +0100] rev 31243
vfs: use 'vfs' module directly in 'mercurial.patch'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:29:43 +0100] rev 31242
vfs: use 'vfs' module directly in 'mercurial.repair'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:28:17 +0100] rev 31241
vfs: use 'vfs' module directly in 'mercurial.localrepo'
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
Jun Wu <quark@fb.com> [Wed, 08 Mar 2017 13:46:26 -0800] rev 31240
chg: forward user-defined signals
SIGUSR1 and SIGUSR2 are reserved for user-defined behaviors. They may be
redefined by an hg extension [1], but cannot be easily redefined for chg.
Since the default behavior (kill) is not that useful for chg, let's forward
them to hg, hoping it got redefined there and could be more useful.
[1] https://bitbucket.org/facebook/hg-experimental/commits/e7c883a465
Jun Wu <quark@fb.com> [Wed, 08 Mar 2017 13:34:25 -0800] rev 31239
chg: document why we send SIGHUP and SIGINT to process group
This makes the code more consistent - other signals are documented.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 08 Mar 2017 14:29:25 -0800] rev 31238
tests: make test-shelve.t timing-independent
It was sometimes taking 2s for me (not the "1s" the test expected).