- Nov 15, 2018
-
-
Matt Harbison authored
It looks like new test coverage in 054d0fcba2c4, rather than a code change.
-
- Nov 13, 2018
-
-
Boris Feld authored
The doctest in these module have been from `mercurial.revlog` but the module was not added to the doctests. Spotted by Yuya Nishihara.
-
- Nov 15, 2018
-
-
Yuya Nishihara authored
-
- Nov 14, 2018
-
-
Augie Fackler authored
I'm getting an annoying failure in this test on our builder, and I *think* what's happening is that the profiler is taking _just_ long enough to start that we're spending 100% of the profiled time in the sleep function, which was causing the leading space to not be printed since the 100 was in the first column of output. Differential Revision: https://phab.mercurial-scm.org/D5272
-
Augie Fackler authored
# skip-blame just b prefixes for py3 Differential Revision: https://phab.mercurial-scm.org/D5271
-
Matt Harbison authored
This is one of the two remaining aborts I found looking into issue5794. I've got no idea what's wrong with the hook, since the changes there fixed the other two problems noted in that bug report. It seems like it might go away when the narrow issue is fixed, but let's make sure this doesn't get lost. The stacktrace for the hook seems to indicate that the missing file *is* in ctx: remote: Traceback (most recent call last): remote: File "c:\Users\Matt\projects\hg\hgext\lfs\__init__.py", line 253, in checkrequireslfs remote: if any(f in ctx and match(f) and ctx[f].islfs() for f in ctx.files()): remote: File "c:\Users\Matt\projects\hg\hgext\lfs\__init__.py", line 253, in <genexpr> remote: if any(f in ctx and match(f) and ctx[f].islfs() for f in ctx.files()): remote: File "c:\Users\Matt\projects\hg\hgext\lfs\wrapper.py", line 191, in filectxislfs remote: return _islfs(self.filelog(), self.filenode()) remote: File "c:\Users\Matt\projects\hg\mercurial\context.py", line 631, in filenode remote: return self._filenode remote: File "c:\Users\Matt\projects\hg\mercurial\util.py", line 1528, in __get__ remote: result = self.func(obj) remote: File "c:\Users\Matt\projects\hg\mercurial\context.py", line 579, in _filenode remote: return self._filelog.lookup(self._fileid) remote: File "c:\Users\Matt\projects\hg\mercurial\filelog.py", line 68, in lookup remote: self._revlog.indexfile) remote: File "c:\Users\Matt\projects\hg\mercurial\utils\storageutil.py", line 218, in fileidlookup remote: raise error.LookupError(fileid, identifier, _('no match found')) remote: LookupError: data/inside2/f.i@f59b4e021835: no match found
-
- Nov 11, 2018
-
-
Yuya Nishihara authored
Before, the logtoprocess extension put a formatted message into $MSG1, and its arguments to $MSG2... If the specified arguments couldn't be formatted because of a caller bug, an unformatted message was passed in to $MSG1 instead of exploding. This behavior doesn't make sense. Since I'm planning to formalize the ui.log() interface such that we'll no longer have to extend the ui class, I want to remove any features not conforming to the ui.log() API. So this patch removes the support for ill-formed arguments, and $MSG{n} (where n > 1) parameters which seems useless as long as the message can be formatted. The $MSG1 variable isn't renamed for the maximum compatibility. In future patches, a formatted msg will be passed to a processlogger object, instead of overriding the ui.log() function. .. bc:: The logtoprocess extension no longer supports invalid ``ui.log()`` arguments. A log message is always formatted and passed in to the ``$MSG1`` environment variable.
-
Yuya Nishihara authored
-
- Nov 13, 2018
-
-
Yuya Nishihara authored
The error message is still cryptic, but it should be better.
-
- Nov 14, 2018
-
-
Anton Shestakov authored
-
Augie Fackler authored
Our automated package builder has some ancient configuration that lacks modern TLS, which is how we noticed this. Tested: the test now passes on both macOS High Sierra (has tls1.2) and Ubuntu Trusty (which does not).
-
- Oct 13, 2018
-
-
Pulkit Goyal authored
Something changed with Python 3 just like million on things. Maybe they should named Python 3 as anaconda or cobra instead of just increasing the version number. This makes test-custom-filters.t pass on Python 3. Differential Revision: https://phab.mercurial-scm.org/D5039
-
- Nov 13, 2018
-
-
Augie Fackler authored
There's no valid manifest that would have no characters before the NUL byte on a line, and this fixes some erratic timeouts in the fuzzer. Differential Revision: https://phab.mercurial-scm.org/D5256
-
- Nov 12, 2018
-
-
Yuya Nishihara authored
I think it's better to include the API overview in core as we now have the internals section in our help system. Retrieved from the wiki, and formatted as reST. Several wiki links are removed since they are invalid in the help. The sections about example extension are removed at all as they seemed too verbose. https://www.mercurial-scm.org/wiki/WritingExtensions
-
- Nov 04, 2018
-
-
Yuya Nishihara authored
This is pretty basic implementation to support GUI progress bar.
-
Yuya Nishihara authored
Otherwise, GUI clients would have to parse the prompt text.
-
Yuya Nishihara authored
These attributes are important to provide a GUI prompt to user.
-
- Nov 08, 2018
-
-
Yuya Nishihara authored
This helps embedding '$' in the script.
-
- Jan 18, 2015
-
-
Yuya Nishihara authored
This provides a 'type' attribute to command-server clients, which seems more solid than relying on 'ui.<type>' labels. In future patches, type='progress' will be added to send raw progress information.
-
Yuya Nishihara authored
This is loosely based on the idea of the TortoiseHg's pipeui extension, which attaches ui.label to message text so the command-server client can capture prompt text, for example. https://bitbucket.org/tortoisehg/thg/src/4.7.2/tortoisehg/util/pipeui.py I was thinking that this functionality could be generalized to templating, but changed mind as doing template stuff would be unnecessarily complex. It's merely a status message, a simple serialization option should suffice. Since this slightly changes the command-server protocol, it's gated by a config knob. If the config is enabled, and if it's supported by the server, "message-encoding: <name>" is advertised so the client can stop parsing 'o'/'e' channel data and read encoded messages from the 'm' channel. As we might add new message encodings in future releases, client can specify a list of encoding names in preferred order. This patch includes 'cbor' encoding as example. Perhaps, 'json' should be supported as well.
-
- Nov 10, 2018
-
-
Yuya Nishihara authored
I was confused how it's working while reviewing fb490d798be0, "share: reload repo after adjusting it in postshare()."
-
Yuya Nishihara authored
-
Yuya Nishihara authored
Since 9aeb9e2d28a7, encoded filenames are filtered by the narrow matcher, which is clearly wrong.
-
Yuya Nishihara authored
This makes encoded filenames differ from the original names.
-
- Nov 07, 2018
-
-
Boris Feld authored
We saw more of these a while back. Having more data available would be nice.
-
- Nov 10, 2018
-
-
Yuya Nishihara authored
-
- Nov 09, 2018
-
-
Martin von Zweigbergk authored
Upstream commit c5e6c1ba1c79 (hg: don't reuse repo instance after unshare(), 2018-09-12) poisoned the repo instance after unshare(). That made `hg unshare` fail with remotefilelog because we tried to close the fileserverclient after dispatch by accessing it via the repo. This patch fixes that by storing the reference to the fileserverclient at the beginning of dispatch. An analogous patch was sent for remotefilelog version in FB's hg-experimental as D5246. Differential Revision: https://phab.mercurial-scm.org/D5253
-
Martin von Zweigbergk authored
When sharing a repo that's using remotefilelog, the update that happens at the end of the `hg share` call does not see the remote repo path that's copied in hg.postshare(). This patch reloads the repo after hg.postshare() to address that. This changes a subrepo test case. Note that `hg share -U; hg co tip` worked there before, so I don't see see why `hg share` should fail. I also don't know what a "locally referenced subrepo". So maybe this is fixing a bug? Hopefully it's not breaking something someone actually cares about at least. Maybe someone who knows and cares about subrepos can review this. Differential Revision: https://phab.mercurial-scm.org/D5251
-
Martin von Zweigbergk authored
The proper way to get the `hg strip` command has been via the "strip" extension since 2013. Differential Revision: https://phab.mercurial-scm.org/D5250
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D5249
-
Martin von Zweigbergk authored
They were added in https://bitbucket.org/facebook/hg-experimental/commits/fdcad37a6a68cfbaf5920f3eeaa0cc9cae42bd26, which says this: When remotefilelog moved from its own repo, the tests needed to be updated to adjust the PYTHONPATH to ensure the in-repo remotefilelog was loaded instead of the system one. This meant any local runs of remotefilelog tests would've been using the system remotefilelog unless the user had manually set the PYTHONPATH themselves. That doesn't seem relevant with remotefilelog in core. Differential Revision: https://phab.mercurial-scm.org/D5248
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D5247
-
- Nov 08, 2018
-
-
Danny Hooper authored
The extra field prevents sequential invocations of fix from producing the same hash twice. Previously, this could cause problems because it would create an obsolescence cycle instead of the expected new successor. This change also adds an explicit check for whether a new revision should be committed. Until now, the code relied on memctx.commit() to quietly do nothing if the node already exists. Because of the new extra field, this no longer covers the case where we don't want to replace an unchanged node. Differential Revision: https://phab.mercurial-scm.org/D5245
-
Danny Hooper authored
This allows changes to the hashes produced by fix to not needlessly modify this area of the test. Differential Revision: https://phab.mercurial-scm.org/D5244
-
- Nov 07, 2018
-
-
Kyle Lippincott authored
I want to add tests after these tests that create a new repo and use it, and was confused for a bit as to why they were seeing different behavior than I expected. Differential Revision: https://phab.mercurial-scm.org/D5242
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D5241
-
- Nov 06, 2018
-
-
Danny Hooper authored
This could be accomplished by using wrapper scripts, but that would diminish the usefulness of the incremental formatting logic. Configuring execution order along with other things in the hgrc is probably more convenient anyway. This change highlights some awkwardness with suboptions and default values, which should be addressed separately. Differential Revision: https://phab.mercurial-scm.org/D5237
-
- Nov 07, 2018
-
-
Augie Fackler authored
I'm curious how the import checker manages to be so much more pedantic in Python 3, but not enough to bother exploring. Differential Revision: https://phab.mercurial-scm.org/D5240
-
Martin von Zweigbergk authored
`sort -r` is better code "formatter" than `tac` since it's stable. It's also portable so we don't need to reimplement it in Python. Differential Revision: https://phab.mercurial-scm.org/D5239
-
Augie Fackler authored
Introduce a tac.py helper and use it. Sigh. Differential Revision: https://phab.mercurial-scm.org/D5238
-