Since this postfix hack exists only for backward compatibility, we don't need
it for new [templates] section. This isn't a BC as templates defined in
[templates] section weren't loaded until recently.
This path is also used for extdiff, which is how I crossed paths with it.
Without this, an AttributeError occurs looking for 'lfstatus' on
localrepository. See also ca0085e432d6.
The other archive method is for the archival.py override, so it doesn't need to
be special cased like this. (It looks like it is only called for the top level
repo.) Likewise, the transplant override is also for commands.py. The other
overrides set lfstatus before examining it.
The only call site called addFailure before raising, which is
exactly what the failure exception handler does. So this
complexity is not needed.
We have test coverage of this "server failed to start" scenario
and nothing appeared to change.
The previous changeset removed the last caller of addWarn(). So,
we rip out that method and all the code related to tracking warned
tests in the results system.
There was even a comment saying we may want to fold warned tests into
the "failed" state, which is what the previous changeset did.
We would raise this if a test didn't return a result code. AFAICT
this can only occur if there is a logic error in the test harness
itself.
I don't think it is worth the code complexity to distinguish this
failure scenario from a regular test failure.
changegroup.apply() currently creates a transation if there isn't
already one. Having the callers of that method pass in an existing
transaction seems a little cleaner. To do that, we need to make sure
all callers have a transaction. Since the transaction name is used as
a hook argument (HG_TXNNAME), we need to match the name from
changegroup.apply().
Several benefits:
* Gets close the comment describing it
* Splits off unrelated comment about "backup" argument
* Error checking is customarily done early
* If we added an early return to the method, it would still
consistently fail if there was an existing transaction (so
we would find and fix that case quickly)
One test needs updating with for this change, because we no longer
create the backup bundle before we fail. I don't see much reason to
create that backup bundle. If some command was adding content and then
trying to strip it as well within the transaction, we would have a
backup for the user, but the risk of that not being discovered in
development seems very small.
I have checked that all callers have already taken the lock (and if
they hadn't, we should have seen tests fail thanks to the 'transaction
requires locking' devel warning in localrepo.transaction()).
Several bits of output were missing[1], unless the DETACHED_PROCESS flag is
_not_ passed to subprocess.Popen(). The problem with that is it briefly opens
and closes several cmd.exe windows on screen. Foozy also mentioned some other
issues in that thread.
With this, the last of the long standing Windows failures fixed, the test suite
now runs cleanly (536 ran, 67 skipped) on Windows 7 x64, with python 2.7.13. \o/
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html
I'm not sure if this is better. If we're planning to add a template keyword
that returns obsoleted nodes unavailable in the repo (i.e. they have no valid
revision numbers), we might want to use the current "node"-only format
everywhere.
I tripped on some weirdness relating to _thread vs threading way down
in a dep of highlight recently. I'm not really sure why I'm only just
seeing this defect now, but experimentally this fixes the problem, and
shouldn't cause any load-time slowness for people until pygments is
actually about to be used since highlight.highlight is still lazily
loaded in the highlight/__init__.py file.
When hghave testing goes awry, the output order was changing on Windows.
diff --git a/tests/test-run-tests.t b/tests/test-run-tests.t
--- a/tests/test-run-tests.t
+++ b/tests/test-run-tests.t
@@ -920,10 +920,10 @@
> EOF
> done
$ rt -j 2
- ....
+ ....skipped: unknown feature: notarealhghavefeature\r (esc)
+
+
# Ran 5 tests, 0 skipped, 0 warned, 0 failed.
- skipped: unknown feature: notarealhghavefeature
-
$ cd ..
$ rm -rf broken
Since 'skipped: unknown feature: notarealhghavefeature\n\n' is printed to stdout
and the rest to stderr, it seems like maybe stdio isn't line buffered on
Windows. When a program exits, stdout is flushed before stderr[1].
[1] https://blogs.msdn.microsoft.com/oldnewthing/20060519-09/?p=31133
On Windows, output streams are buffered when redirected to a file, and
TerminateProcess() apparently doesn't trigger a flush. This left
test-http-proxy.t missing part of the last line when it cat'd proxy.log[1].
Flushing stderr is all that is needed (on py27 anyway). I originally flushed
stdout too, but that added additional output to the log:
$ cat proxy.log
+ Accept: $LOCALIP (localhost)\r (esc)
+ Serving HTTP on 0.0.0.0 port 20810 ...\r (esc)
+ connect to localhost:$HGPORT\r (esc)
* - - [*] "GET http://localhost:$HGPORT/?cmd=capabilities HTTP/1.1" - - (glob)
+ bye\r (esc)
+ connect to localhost:$HGPORT\r (esc)
* - - [*] "GET http://localhost:$HGPORT/?cmd=branchmap HTTP/1.1" - - x-hgproto-1:0.1 0.2 comp=*zlib,none,bzip2 (glob)
+ bye\r (esc)
+ connect to localhost:$HGPORT\r (esc)
* - - [*] "GET http://localhost:$HGPORT/?cmd=stream_out HTTP/1.1" - - x-hgproto-1:0.1 0.2 comp=*zlib,none,bzip2 (glob)
+ bye\r (esc)
+ connect to localhost:$HGPORT\r (esc)
...
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html
This can happen if another process (even another hg process!) comes along and
removes the file at that time.
This partly resolves issue5584, but not completely -- a bogus dirstate update
can still happen. However, the full fix is too involved for stable.
