util: wrap lines with multi-byte characters correctly (
issue2943)
This re-introduces the unicode conversion what was lost in
d320e70442a5 5 years
ago and had the comment:
To avoid corrupting multi-byte characters in line, we must wrap
a Unicode string instead of a bytestring.
setdiscovery: fix hang when #heads>200 (
issue2971)
When setting up the next sample, we always add all of the heads, regardless
of the desired max sample size. But if the number of heads exceeds this
size, then we don't add any more nodes from the still undecided set.
(This is debatable per se, and I'll investigate it, but it's how we designed
it at the moment.)
The bug was that we always added the overall heads, not the heads of the
remaining undecided set. Thus, if #heads>200 (desired sample size), we
did not make progress any longer.
ui: also swap sys.stdout with self.fout in _readline
In
17ffb30d9174, _readline was changed to output a space using
raw_input and this was done using sys.stdout directly, not self.fout.
This change broke the command server for JavaHg since it (and other
clients) would see a spurious ' ' on stdout and interpret this as an
unknown channel.
Added signature for changeset
d629f1e89021
Added tag 1.9.2 for changeset
d629f1e89021
atomictempfile: make close() consistent with other file-like objects.
The usual contract is that close() makes your writes permanent, so
atomictempfile's use of close() to *discard* writes (and rename() to
keep them) is rather unexpected. Thus, change it so close() makes
things permanent and add a new discard() method to throw them away.
discard() is only used internally, in __del__(), to ensure that writes
are discarded when an atomictempfile object goes out of scope.
I audited mercurial.*, hgext.*, and ~80 third-party extensions, and
found no one using the existing semantics of close() to discard
writes, so this should be safe.