Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:47 +0100] rev 31237
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 31236
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 31235
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 31234
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 31233
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 31232
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 31231
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 31230
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 31229
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 31228
tests: make test-shelve.t timing-independent
It was sometimes taking 2s for me (not the "1s" the test expected).