- Jan 21, 2018
-
-
Matt Harbison authored
If you think 'C:' and 'C:\' are equivalent paths, see the inline comment before proceeding. The problem here was that several commands that take a URL argument (incoming, outgoing, pull, and push) will use that value to set 'repo._subtoppath' on the repository object after command specific manipulation of it, but before converting it to an absolute path. When an operation is performed on a relative subrepo, subrepo._abssource() will posixpath.join() this value with the relative subrepo path. That adds a '/' after the drive letter, changing how it is evaluated by abspath()/realpath() in vfsmod.vfs(..., realpath=True) as the subrepo is instantiated. I initially tried sanitizing the path in url.localpath(), because url.isabs() only checks that it starts with a drive letter. By the sample behavior, this is clearly not an absolute path. (Though the comment in isabs() is weasely- this style path can't be joined either.) But not everything funnels through there, and it required explicitly calling localpath() in hg.parseurl() and assigning to url.path to fix. But then tests failed with urls like 'a#0'. Next up was sanitizing the path in the url constructor. That caused doctest failures, because there are drive letter tests, so those got expanded in system specific ways. Yuya correctly pointed out that util.url is a parser, and shouldn't be substituting the path too. Rather than fixing every command call site, just convert it in the common subrepo location. I don't see any sanitizing on the path config options, so I fixed those too. Note that while the behavior is fixed here, there are still places where 'comparing with C:' gets printed out, and that's not great for debugging purposes. (Specifically I saw it in `hg incoming -B C:`, without subrepos.) While clone will write out an absolute default path, I wonder what would happen if a user edited that path to be 'C:'. (I don't think supporting relative paths in .hgrc is a sane thing to do, but while we're poking holes in things...) Since this is such an oddball case, it still leaks through in places, and there seems to be a lot of duplicate url parsing, maybe the url parsing should be moved to dispatch, and provide the command with a url object? Then we could convert this to an absolute path once, and not have to worry about it in the rest of the code. I also checked '--cwd C:' on the command line, and it was previously working because os.chdir() will DTRT. Finally, one other note from the url.localpath() experimenting. I don't see any cases where 'self._hostport' can hold a drive letter. So I'm wondering if that is wrong/old code.
-
- Jan 22, 2018
-
-
Matt Harbison authored
The connection refused error in test-patchbomb-tls.t[1] is sporadic, but one of the more often seen errors on Windows. I added enough logging to a file and dumped it out at the end to make the following observations: - The listening socket is successfully created and bound to the port, and the "listening at..." message is always logged. - Generally, the following is the entire log output, with the "accepted ..." message having been added after `sslutil.wrapserversocket`: listening at localhost:$HGPORT $LOCALIP ssl error accepted connect accepted connect $LOCALIP from=quux to=foo, bar $LOCALIP ssl error - In the cases that fail, asyncore.loop() in the run() method is exiting, but not with an exception. - In the cases that fail, the following is logged right after "listening ...": Traceback (most recent call last): File "c:\\Python27\\lib\\asyncore.py", line 83, in read obj.handle_read_event() File "c:\\Python27\\lib\\asyncore.py", line 443, in handle_read_event self.handle_accept() File "../tests/dummysmtpd.py", line 80, in handle_accept conn = sslutil.wrapserversocket(conn, ui, certfile=self._certfile) File "..\\mercurial\\sslutil.py", line 570, in wrapserversocket return sslcontext.wrap_socket(sock, server_side=True) File "c:\\Python27\\lib\\ssl.py", line 363, in wrap_socket _context=self) File "c:\\Python27\\lib\\ssl.py", line 611, in __init__ self.do_handshake() File "c:\\Python27\\lib\\ssl.py", line 840, in do_handshake self._sslobj.do_handshake() error: [Errno 10054] $ECONNRESET$ - If the base class handler is overridden completely, the the first "ssl error" line is replaced by the stacktrace, but the other lines are unchanged. The client behaves no differently, whether or not the server stacktraced. In general, `./run-tests.py --local -j9 -t9000 test-patchbomb-tls.t --runs-per-test 20` would show the issue after a run or two. With this change, `./run-tests.py --local -j9 -t9000 test-patchbomb-tls.t --loop` ran 800 times without a hiccup. This makes me wonder if the other connection refused messages that bubble up on occasion are caused by a similar issue. It seems a bit drastic to kill the whole server on account of a single communication failure with a client. # no-check-commit because of handle_error() [1] https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/421/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio
-
- Jan 21, 2018
-
-
André Sintzoff authored
MIN macro is defined in <sys/param.h> on macOS Sierra. Therefore as HAVE_BSD_STATFS is defined in osutil.c, 'MIN' macro redefined warning is emitted.
-
Anton Shestakov authored
January seems to be a good month to do this.
-
Anton Shestakov authored
Other tests already do this.
-
- Jan 20, 2018
-
-
Matt Harbison authored
-
Matt Harbison authored
-
Matt Harbison authored
-
Matt Harbison authored
This seems more descriptive.
-
Matt Harbison authored
-
- Jan 17, 2018
-
-
Boris Feld authored
When stream clone is used over bundle2, relevant cache files are also streamed. This is expected to be a massive performance win for clone since no important cache will have to be recomputed. Some performance numbers: (All times are wall-clock times in seconds, 2 attempts per case.) # Mozilla-Central ## Clone over ssh over lan V1 streaming: 234.3 239.6 V2 streaming: 248.4 243.7 ## Clone over ssh over Internet V1 streaming: 175.5 110.9 V2 streaming: 109.1 111.0 ## Clone over HTTP over lan V1 streaming: 105.3 105.6 V2 streaming: 112.7 111.4 ## Clone over HTTP over internet V1 streaming: 105.6 114.6 V2 streaming: 226.7 225.9 ## Hg tags V1 streaming (no cache): 1.084 1.071 V2 streaming (cache): 0.312 0.325 ## Hg branches V1 streaming (no cache): 14.047 14.148 V2 streaming (with cache): 0.312 0.333 # Pypy ## Clone over ssh over internet V1 streaming: 29.4 30.1 V2 streaming: 31.2 30.1 ## Clone over http over internet V1 streaming: 29.7 29.7 V2 streaming: 75.2 72.9 (since ssh and lan are not affected, there seems to be an issue with how we read/write the http stream on connection with latency, unrelated to the format) ## Hg tags V1 streaming (no cache): 1.752 1.664 V2 streaming (with cache): 0.274 0.260 ## Hg branches V1 streaming (no cache): 4.469 4.728 V2 streaming (with cache): 0.318 0.321 # Private repository: * 500K revision revisions * 11K topological heads * 28K branch heads ## hg tags no cache: 1543.332 with cache: 4.900 ## hg branches no cache: 91.828 with cache: 2.955
-
Boris Feld authored
For more code to use this information, we need it to be more publicly available.
-
Boris Feld authored
The phaseroots are stored in a non append-only file in the repository. We include them in the stream too. Since they are not append-only, we have to keep a copy around while we hold the lock to be able to stream them later. Since phase get exchanged within the stream we can skip requesting them independently. As a side effect, this will fixes issue5648 once the feature is enabled by default.
-
- Jan 18, 2018
-
-
Boris Feld authored
We add a test dedicated to phases. As reported in issue 5648 stream from a non publishing server is currently broken (does not preserve the phase). We'll fix it with 'v2' support in the next changesets.
-
- Jan 17, 2018
-
-
Boris Feld authored
The feature put to use the various bits introduced previously. If the server supports it, the client will request its stream clone through bundle2 instead of the legacy 'stream_out' commands. The bundle2 version use the better 'v2' version of stream bundles. The 'v2' format is not finalized yet. Now that there are some code running it, we can start working on it again. Performance numbers are available at the end of this series.
-
Boris Feld authored
Next changesets will add support for using stream cloning with bundle2. We introduce indentation change first for clarity.
-
Boris Feld authored
We are about to add the ability to use stream bundle with bundle2. Before doing so, we need to gather some code that will not be used in the bundle2 case. There is no behavior change within this changeset.
-
Boris Feld authored
The previous check was a bit too strict and would not recognize a get bundle not requesting changegroup.
-
Boris Feld authored
This parameter can be used to request a stream bundle.
-
Boris Feld authored
The part contains the necessary arguments and payload to handle a stream bundle v2. It will be put to use in later changesets.
-
Boris Feld authored
There is code about bundle2 laying around in `canperformstreamclone` but not put to any uses. As we discovered with the previous patch, streambundle 'v1' won't work on bundle2 because they are readline based. So we jump to 'v2' as the first expected supported version.
-
Boris Feld authored
(This patch is based on a first draft from Gregory Szorc, with deeper rework) Version 1 of the stream clone format was invented many years ago and suffers from a few deficiencies: 1) Filenames are stored in store-encoded (on filesystem) form rather than in their internal form. This makes future compatibility with new store filename encodings more difficult. 2) File entry "headers" consist of a newline of the file name followed by the string file size. Converting strings to integers is avoidable overhead. We can't store filenames with newlines (manifests have this limitation as well, so it isn't a major concern). But the big concern here is the necessity for readline(). Scanning for newlines means reading ahead and that means extra buffer allocations and slicing (in Python) and this makes performance suffer. 3) Filenames aren't compressed optimally. Filenames should be compressed well since there is a lot of repeated data. However, since they are scattered all over the stream (with revlog data in between), they typically fall outside the window size of the compressor and don't compress. 4) It can only exchange stored based content, being able to exchange caches too would be nice. 5) It is limited to a stream-based protocol and isn't suitable for an on-disk format for general repository reading because the offset of individual file entries requires scanning the entire file to find file records. As part of enabling streaming clones to work in bundle2, #2 proved to have a significant negative impact on performance. Since bundle2 provides the opportunity to start fresh, Gregory Szorc figured he would take the opportunity to invent a new streaming clone data format. The new format devised in this series addresses #1, #2, and #4. It punts on #3 because it was complex without yielding a significant gain and on #5 because devising a new store format that "packs" multiple revlogs into a single "packed revlog" is massive scope bloat. However, this v2 format might be suitable for streaming into a "packed revlog" with minimal processing. If it works, great. If not, we can always invent stream format when it is needed. This patch only introduces the bases of the format. We'll get it usable through bundle2 first, then we'll extend the format in future patches to bring it to its full potential (especially #4).
-
- Jan 19, 2018
-
-
Gregory Szorc authored
This will be useful in an incoming version-2 of the stream format.
-
Boris Feld authored
This function is used in multiple place, having it in util would be better. (existing caller will be migrated in another series)
-
- Jan 20, 2018
-
-
Matt Harbison authored
-
- Jan 19, 2018
-
-
Siddharth Agarwal authored
I noticed that we didn't have any unit tests covering wire protocol argument parsing.
-
Augie Fackler authored
-
- Jan 12, 2018
-
-
Jörg Sonnenberger authored
A couple of commands currently require transmission of uncompressed frames with the old MIME type. Split this case from streamres into a new streamres_legacy class. Streamline the remaining code accordingly. Add a new flag to streamres to request uncompressed streams. This is useful for sending data that is already compressed like a pre-built bundle. Expect clients to support uncompressed data. For older clients, zlib will still be used. Differential Revision: https://phab.mercurial-scm.org/D1862
-
- Jan 19, 2018
-
-
Martin von Zweigbergk authored
See in-code comment for details. Differential Revision: https://phab.mercurial-scm.org/D1918
-
Martin von Zweigbergk authored
Before this patch, the transaction name was '%2i-txnreport', which means the first one would be ' 0-txnreport'. It seems more intuitive for sorting purposes (the callbacks are called in lexicographical order) to make it 0-padded. Differential Revision: https://phab.mercurial-scm.org/D1917
-
- Jan 17, 2018
-
-
Boris Feld authored
Bookmarks are not stored in `.hg/store`. We need to make sure they are cloned with `--stream`.
-
- Jan 19, 2018
-
-
Pulkit Goyal authored
With the functionality added in previous patch we can change branches of a revision but not everytime even if it's possible to do so. For example cosider the following case: o 3 added a (foo) o 2 added b (foo) o 1 added c (bar) o 0 added d (bar) Here if I want to change the branch of rev 2,3 to bar, it was not possible and it will say, "a branch with same name exists". This patch allows us to change branch of 2,3 to bar. The underlying logic for changing branch finds the changesets from the revs passed which have no parents in revs. We only support revsets which have only one such root, so to support this we check whether the parent of the root has the same name as that of the new name and if so, we can use the new name to change branches. Differential Revision: https://phab.mercurial-scm.org/D1913
-
- Oct 15, 2017
-
-
Pulkit Goyal authored
This patch adds a new --rev flag to hg branch which can be used to change branch of revisions. This is motivated from topic extension where you can change topic on revisions but this one has few restrictions which are: 1) You cannot change branch name in between the stack 2) You cannot change branch name and set it to an existing name 3) You cannot change branch of non-linear set of commits 4) You cannot change branch of merge commits. Tests are added for the same. .. feature:: An experimental flag `--rev` to `hg branch` which can be used to change branch of changesets. Differential Revision: https://phab.mercurial-scm.org/D1074
-
- Jan 16, 2018
-
-
Yuya Nishihara authored
'exp' may be None because of '(group None)' node. The error message is copied from revset.py.
-
Yuya Nishihara authored
-
- Jan 18, 2018
-
-
Hollis Blanchard authored
In 2015 there was a workaround added (f39bace2d6cad32907c0d7961b3c0dbd64a1b7ad) to sparse in the hg-experimental repo. That workaround: a) no longer seems to be needed, since its testcase passes even with the code removed, and b) caused a new problem: --include 'dir1/dir2' ended up including dir1/* too. (--include 'glob:dir1/dir2' is a user-level workaround.) Remove the offending code, and add a testcase for situation B.
-
- Jan 14, 2018
-
-
Yuya Nishihara authored
":" isn't taken as a symbol character but an infix operator so we can write e.g. "path:'foo bar'" as well as "'path:foo bar'". An invalid pattern kind is rejected in the former form as we know a kind is specified explicitly. The binding strength is copied from "x:y" range operator of revset. Perhaps it can be adjusted later if we want to parse "foo:bar()" as "(foo:bar)()", not "foo:(bar())". We can also add "kind:" postfix operator if we want. One possible confusion is that the scope of the leading "set:" vs "kind:pat" operator. The former is consumed by a matcher so applies to the whole fileset expression: $ hg files 'set:foo() or kind:bar or baz' ^^^^^^^^^^^^^^^^^^^^^^^^ Whereas the scope of kind:pat operator is narrow: $ hg files 'set:foo() or kind:bar or baz' ^^^
-
Yuya Nishihara authored
They must be identical for fileset compatibility.
-
Yuya Nishihara authored
Actually there was no circular import issue.
-
Paul Morelle authored
Extracting these methods from revlog will allow changing the implementation of the deltacomputer, by providing this interface: __init__(self, revlog) - constructor that initialize the object from a given revlog buildtext(self, revinfo, fh) - builds the fulltext version of a revision from a _revisioninfo object and the file handle to the .d (or .i for inline mode) file. finddeltainfo(self, revinfo, fh) - find a revision in the revlog against which it is acceptable to build a delta, and build the corresponding _deltainfo. It should now be easier to write an experimental feature that would replace _deltacomputer by another object, for example one that would know how to parallelize the delta computation in order to quicken the storage of multiple revisions.
-