- Mar 18, 2018
-
-
Matt Harbison authored
These changes started with 2090044a288d. They aren't important to LFS testing.
-
- Mar 11, 2018
-
-
Yuya Nishihara authored
-
- Mar 15, 2018
-
-
Martin von Zweigbergk authored
Before this patch and when the rebase involved the working copy parent (and thus the working copy too), we would not do in-memory rebase even if requested to. The in-code comment explains that the reason had something to do with avoiding an extra update, but I don't know which update that refers to. Perhaps an earlier version of the code used to update to the destination before rebasing even if in-memory rebase was requested? That seems to not be done at least since aa660c1203a9 (rebase: do not bail on uncomitted changes if rebasing in-memory, 2017-12-07). To see if this still made it slower, I create a single tiny commit on top of one branch of the mozilla-unified repo (commit a1098c82 to be exact) and rebased it to another branch (commit d4e9a7be). Before this patch that took 11.8s and after this patch it took 8.6s (I only did two runs each, but the timings were very consistent). Differential Revision: https://phab.mercurial-scm.org/D2876
-
- Mar 17, 2018
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D2890
-
- Mar 14, 2018
-
-
Martin von Zweigbergk authored
We had instructions for our internal users to add copy information after commit like this: hg uncommit <srcfile> <dstfile> hg cp --after <srcfile> <dstfile> hg amend That usually works, but if the rename was the only change in that commit, then the commit would get pruned. It's easy to fix the recipe: just pass the --keep option. However, it seems too subtle, so I think this is an indication that the commit should not be pruned if any patterns were given. Differential Revision: https://phab.mercurial-scm.org/D2862
-
- Mar 16, 2018
-
-
Yuya Nishihara authored
If the custom engine, "mytemplater", were installed as the default, it would enter to an infinite recursion at stringify(v) because template keywords may generate a nested mapping containing the same keywords. Spotted by a future patch which will replace context.resource('templ')(...) with context.process(...).
-
Yuya Nishihara authored
-
- Mar 15, 2018
-
-
Yuya Nishihara authored
-
- Jan 18, 2018
-
-
Boris Feld authored
The feature is now advertised and use. Updating the branchmap cache can be very expensive (up to minutes on large repository) and fetching revision branch data is about 80% of that. Exchanging the rev branch cache over the wire really help to recover from branch map invalidation. (There is a good chance other in flight chance would conflict on test-http-bad-server.t and other. So here is a small note to help update that test again: capabilities=19bytes, part-107bytes)
-
- Feb 21, 2018
-
-
Boris Feld authored
`hg bundle` command producing bundle2 will now include an optional part containing the revision-branch cache data. The data sent are mostly nodes so it is quite compact. The goal of the rev-branch-cache is to speed up branch map computation, especially when the branchmap gets invalidated so we send data for all exchanged changesets. In addition, computing the relevant heads to send in case of partial pulling would be challenging. As a reminder, the rev branch cache data significantly speed up branch computation. Having it around provides a small speedup to pull/clone and much higher tolerance to branch map cache invalidation that might happens from later commands. On the Mercurial repository, computing the visible branchmap from scratch move from 2.00 seconds to 0.34s (a -83% speedup). Using this new part, Unbundling the full Mercurial repository moves from 25.736 seconds to 24.030 seconds (around -7% speedup). The bundle size increase is around 3% (from 22.43 MB to 23.13MB) On an half a million revision repository with twenty thousand branches, computing the branchmap moves from 75 seconds to 45 second (-40%) if the caches is used. A bundle containing 50 000 changesets in such repository get a 0.5% size increase from such part for a -3% unbundling time speedup.
-
- Feb 26, 2018
-
-
Anton Shestakov authored
-
Anton Shestakov authored
This is a port of evolve's feature of listing all unstable changesets in detail (`hg evolve --list`).
-
- Feb 21, 2018
-
-
Boris Feld authored
This changeset makes `hg debugbundle` respect --quiet and only display data about part headers.
-
- Mar 14, 2018
-
-
Augie Fackler authored
These are also fallout from the check-code regex rewriting bug. Differential Revision: https://phab.mercurial-scm.org/D2865
-
Augie Fackler authored
This pattern was banned by check-code way back in 1b4b82063ce2 (may of 2011), but due to a regular expression rewriting bug in check-code these particular callsites were never detected. Python 3.7 caught the bug, which then exposed these errors. Differential Revision: https://phab.mercurial-scm.org/D2863
-
- Mar 05, 2018
-
-
Boris Feld authored
A batch commands encapsulate multiple other commands. We display a bit more details about what is actually batched if peer request tracking is set.
-
- Mar 14, 2018
-
-
Augie Fackler authored
This started failing recently, but it doesn't look important as no actual ui objects have been in play. Differential Revision: https://phab.mercurial-scm.org/D2867
-
Augie Fackler authored
This made some debugging a lot less painful when something was broken, and it costs us almost nothing, so I figure we may as well leave it in. Differential Revision: https://phab.mercurial-scm.org/D2853
-
- Mar 13, 2018
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D2846
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D2845
-
- Mar 10, 2018
-
-
Sushil Khanchi authored
-
- Mar 12, 2018
-
-
Yuya Nishihara authored
-
- Mar 08, 2018
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D2759
-
- Mar 09, 2018
-
-
Martin von Zweigbergk authored
When rebase.singletransaction is set, we still used to create a second transaction when committing with --collapse. It's simpler to create a single transaction. Note that in the affected .t file, the test that uses --collapse still appears to create two transactions (it prints "rebase status stored" twice). However, only a single transaction is actually created and the second printout comes from cmdutil.commitforceeditor() that explicitly calls tr.writepending(). Also note the that we now roll back any commits if the user closes the commit message editor with an error code (or leaves the message empty). That might be unfortunate, but it's consistent with how we behave in the --no-collapse case (if the user passed --edit). If we want to change that, I think it should be done consistently in a separate patch. Differential Revision: https://phab.mercurial-scm.org/D2728
-
- Mar 13, 2018
-
-
Matt Harbison authored
This has been extremely valuable to show divergences between `hg serve` and `lfs-test-server`. Once the `hg serve` code lands, there will be a certain amount of conditionalizing that needs to be done, because `lfs-test-server` doesn't always follow its spec. The $ISO_8601_DATE_TIME$ pattern masks the fact that `lfs-test-serve` is sending out an expires_at value of "0001-01-01T00:00:00Z". `hg serve` will (probably) use current time + 10 minutes or similar. The $HTTP_DATE$ is the current time.
-
Matt Harbison authored
This will be useful to let the client print out the HTTP headers and JSON in a future patch, so we can compare native LFS serving against test-lfs-server behavior. There tends to be a lot of debug stuff that we don't care about here in a push, so I was tempted to print this output with a [devel] config. But this will be useful for field debugging too, so just put up with the extra output here. It would have been nice to be able to set ui.debug once, but issue5815 prevents that.
-
- Feb 24, 2018
-
-
Matt Harbison authored
This will be useful when printing HTTP headers and JSON payload received from an LFS server. The RFC 1123 date masking has uses elsewhere too.
-
- Mar 08, 2018
-
-
Yuya Nishihara authored
As we have a util module, it doesn't make sense to import stringify() from templatefilters.py.
-
- Feb 28, 2018
-
-
Yuya Nishihara authored
The annotate logic is large. Let's move it out of the context module, which is basically an abstraction layer of repository operations.
-
- Mar 11, 2018
-
-
Gregory Szorc authored
Good riddance. .. api:: The old ``wsgirequest`` class for handling everything WSGI in hgweb has been replaced by separate request and response types. Various high-level functions in the hgweb WSGI applications now receive these new types as arguments instead of the old ``wsgirequest`` type. Differential Revision: https://phab.mercurial-scm.org/D2832
-
Gregory Szorc authored
The web.baseurl config option allows server operators to define a custom URL for hosted content. The way it works today is that hgwebdir parses this config option into URL components then updates the appropriate WSGI environment variables so the request "lies" about its details. For example, SERVER_NAME is updated to reflect the alternate base URL's hostname. The WSGI environment should not be modified because WSGI applications may want to know the original request details (for debugging, etc). This commit teaches our request parser about the existence of an alternate base URL. If defined, the advertised URL and other self-reflected paths will take the alternate base URL into account. The hgweb WSGI application didn't use web.baseurl. But hgwebdir did. We update hgwebdir to alter the environment parsing accordingly. The old code around environment manipulation has been removed. With this change, parserequestfromenv() has grown to a bit unwieldy. Now that practically everyone is using it, it is obvious that there is some unused features that can be trimmed. So look for this in follow-up commits. Differential Revision: https://phab.mercurial-scm.org/D2822
-
Gregory Szorc authored
When I implemented the new request object, I carried forward some ugly hacks until I could figure out what was happening. One of those was the handling of PATH_INFO to determine how to route hgweb requests. Essentially, if we have PATH_INFO data, we route according to that. But if we don't, we route by the query string. I question if we still need to support query string routing. But that's for another day, I suppose. In this commit, we clean up the ugly "havepathinfo" hack and replace it with a "dispatchpath" attribute that can hold None or empty string to differentiate between the presence of PATH_INFO. This is still a bit hacky. But at least the request parsing and routing code is explicit about the meaning now. Differential Revision: https://phab.mercurial-scm.org/D2820
-
Gregory Szorc authored
The hgwebdir WSGI application detects when a requested URL is for a known repository and it effectively forwards the request to the hgweb WSGI application. The hgweb WSGI application needs to route the request based on the base URL for the repository. The way this normally works is SCRIPT_NAME is used to resolve the base URL and PATH_INFO contains the path after the script. But with hgwebdir, SCRIPT_NAME refers to hgwebdir, not the base URL for the repository. So, there was a hacky REPO_NAME environment variable being set to convey the part of the URL that represented the repository so hgweb could ignore this path component for routing purposes. The use of the environment variable for passing internal state is pretty hacky. Plus, it wasn't clear from the perspective of the URL parsing code what was going on. This commit improves matters by making the repository name an explicit argument to the request parser. The logic around handling of this value has been shored up. We add various checks that the argument is used properly - that the repository name does represent the prefix of the PATH_INFO. Differential Revision: https://phab.mercurial-scm.org/D2819
-
Gregory Szorc authored
A subsequent commit will need to make this code more complicated in order to support alternate base URLs. Let's establish some test coverage before we diverge too far from PEP 3333. As part of this, a minor bug related to a missing SCRIPT_NAME key has been squashed. Differential Revision: https://phab.mercurial-scm.org/D2818
-
Gregory Szorc authored
We have effectively removed all consumers of the old wsgirequest type. The templater can be accessed on the requestcontext passed into the @webcommand function. For the most part, these arguments are unused. They only exist to provide backwards compatibility. And in the case of wsgirequest, use of that object could actively interfere with the new request object. So let's stop passing these objects to @webcommand functions. With this commit, wsgirequest is practically dead from the hgweb WSGI application. There are still some uses in hgwebdir though... .. api:: @webcommand functions now only receive a single argument. The request and templater instances can be accessed via the ``req`` and ``templater`` attributes of the first argument. Note that the request object is different from previous Mercurial releases and consumers of the previous ``req`` 2nd argument will need updating to use the new API. Differential Revision: https://phab.mercurial-scm.org/D2803
-
Gregory Szorc authored
We're trying to remove ``wsgirequest``. The permissions hooks don't do anything they can't do with our new request type. So let's pass that in. This was the last use of ``wsgirequest`` in the wire protocol code! .. api:: hgweb.hgweb_mod.permhooks no longer take a ``wsgirequest`` instance as an argument. Differential Revision: https://phab.mercurial-scm.org/D2793
-
Gregory Szorc authored
Well, I tried to go with PEP 3333's recommendations and only allow our WSGI application to emit data via a response generator. Unfortunately, the "archive" command calls into the zipfile and tarfile modules and these operator on file objects and must send their data to an object with write(). There's no easy way turn these write() calls into a generator. So, we teach our response type how to expose a file object like object that can be used to write() output. We try to keep the API consistent with how things work currently: callers must call a setbody*(), then sendresponse() to trigger sending of headers, and only then can they get a handle on the object to perform writing. This required overloading the return value of @webcommand functions even more. Fortunately, we're almost completely ported off the legacy API. So we should be able to simplify matters in the near future. A test relying on this functionality has also been updated to use the new API. Differential Revision: https://phab.mercurial-scm.org/D2792
-
Gregory Szorc authored
This command is special in a few ways. First, it is the only command using the write() function from WSGI's start_response() function. Second, it is setting a custom content-disposition header. We change the test so it prints out full details of the HTTP response. We also save the response body to a file so we can verify its size and hash. The hash check will help ensure that archive generation is deterministic. Differential Revision: https://phab.mercurial-scm.org/D2790
-
- Mar 10, 2018
-
-
Gregory Szorc authored
I think I managed to update all call sites using wsgirequest.form to use parsedrequest.qsparams. Since behavior of qsparams is to retrieve last value, behavior will change if a parameter was specified multiple times. But I think this is acceptable. I'm not a fan of the `req.req.qsparams` pattern. And some of the modified code could be written better. But I was aiming for a straight port with this change. Cleanup can come later. Differential Revision: https://phab.mercurial-scm.org/D2781
-
Gregory Szorc authored
We have code that validates that wire protocol commands (which are specified via query string) must occur at the base URL of a repo. But we have no test coverage for this behavior. Let's add some. Differential Revision: https://phab.mercurial-scm.org/D2778
-