The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Because pipe-mode server uses stdio as IPC channel, other modules should not
touch stdio directly and use ui instead. However, this strategy is brittle
because several Python functions read and write stdio implicitly.
print 'hello' # should use ui.write()
# => ch = 'h', size = 1701604463 'ello', data = '\n'
This patch adds protection for such mistakes. Both stdio files and low-level
file descriptors are redirected to /dev/null while command server uses them.
Because unix-mode server forks child process per connection, client does not
know the pid of the server that will handle requests. The pid is necessary
to interrupt hung process:
1. client connects to socket server
2. server accepts the connection, forks, and tells pid
3. client requests "runcommand pull"
.. hung ..
4. client sends SIGINT to the (forked) server
5. server returns from I/O wait
Note that getsockopt(SO_PEERCRED) of Linux cannot be used because the server
fork()s after accept().
Typical use case of 'unix' mode is a background hg daemon.
$ hg serve --cmdserver unix --cwd / -a /tmp/hg-`id -u`.sock
Unlike 'pipe' mode in which parent process keeps stdio channel, 'unix' server
can be detached. So clients can freely connect and disconnect from server,
saving Python start-up time.
It might be better to write "--cmdserver socket -a unix:/sockpath" instead
of "--cmdserver unix -a /sockpath" in case hgweb gets the ability to listen
on unix domain socket.
This is the stub for new mode that will listen for connections on unix domain
socket.
Though --daemon option is not banned in 'pipe' mode, it is useless because
the detached 'pipe' mode server exits immediately due to null stdin. Should
it abort if --daemon is specified with --cmdserver pipe or --stdio?
The previous patch makes sure that in_ == out, so it's no longer needed
to keep in_ for __getattr__. Also, it seems strange for channeledoutput
to have in_ stream which is actually a writable file object.
It seems wrong to get attributes from object different than the underlying
file. In the following example, it doesn't make sense to flush stderr after
writing to stdout:
self.ferr.write(str(a))
if not getattr(self.ferr, 'closed', False):
self.ferr.flush()
Command server is designed to use the channel protocol even if the server
process is accessible to tty, whereas vanilla hg should be able to read
password from tty in that case. So it isn't enough to swap sys.stdin:
# works only if the server process is detached from the console
sys.stdin = self.fin
getpass.getpass('')
sys.stdin = oldin
or test isatty:
# vanilla hg can't talk to tty if stdin is redirected
if self._isatty(self.fin):
return getpass.getpass('')
else:
...
Since ui.nontty flag is undocumented and command-server channels don't provide
isatty(), this change won't affect the other uses of ui._isatty().
issue3161 also suggests to provide some context of messages. I think it can
be implemented by using the generic templating function.
Typical use case is to clone repository through command server. Clone may
require user interaction, so command-server protocol is beneficial over
raw stdio channels.
"hg help" does not state that the code for abort is 255, but it's confusing
to have different code between hg command and command server.
Tests of python-hglib 1.2 passed with this change.
MQ extension will wrap this function to invalidate its state.
repo.invalidate cannot be wrapped for this purpose because qpush obtains
repo.lock in the middle of the operation, triggering repo.invalidate. Also,
it seems wrong to obtain lock earlier because mq data is non-store parts.
Copying a repos local configuration to another repo is a bad idea because the
2nd repo gets the configuration of the first. Prevent this by really calling
repo.baseui.copy when repo.ui.copy is called.
This requires some changes in commandserver which needs to clone repo.ui for
rejecting temporary changes.
This patch has its roots back in the topic "repo isolation" around 68ae3063a47d
and was suggested by mpm.
The dirstate is invalidated separately outside of invalidate() which is
already being called (other callers of invalidate() seems to suggest the
separation is there for a reason).
This will trigger the filecache and recreate every cached property that was
changed by something other than this cmdserver instance (e.g. by running
'hg commit' at the cmdline).
The ui passed to server() is really repo.ui, that is it contains its local
configuration as well.
When running commands that use a different repo than the servers cached repo,
we don't want to use that ui as the baseui for the new repo.
There are places in the code that use localrepository.baseui (see hg.remoteui),
we need the ui descriptors (and possibly other things) to be set
correctly on it, so output written to the remoteui descriptors ends up at the
right place.
Before this change, tests such as 'test-bookmarks-pushpull.t' didn't work.
This is a guaranteed by the protocol: clients know they need to read one chunk
off of the 'o' channel and treat that as the hello message.
They should ignore fields they don't recognize so they stay compatible with
new versions of the server in case we decide to add something.
No real reason for a client to do this, but still possible.
Previously if the client sent no arguments, a list with an empty string ['']
would be used as the arguments to dispatch, which would cause hg to complain
about an ambiguous command.
Instead, we simply check for no arguments and use an empty list instead (which
is equivalent to invoking hg with no args on the command line).
