- Jun 05, 2018
-
-
Boris Feld authored
Keeping shelve changeset around increase the risk of collision with normal changesets. To prevent such collision and help with overall clarity, we add an 'internal' key in extra that mark the changeset as created by "shelve". Node changes in tests are expected.
-
Boris Feld authored
Keeping an explicit reference to the shelve node in order to reuse it directly if the unshelved is repeated (eg: unshelve --keep).
-
Boris Feld authored
This prepares the version of shelve that would not strip the shelved node from the repository. If we have the node information, search for it in the repository and only fallback on unbundling if it is missing. To be able to find such nodes, we operate on an unfiltered repository.
-
Boris Feld authored
To build a version of shelve that use hiding instead of stripping, we need shelve to be able to find these revisions. This it does not hurt the bundle version, so we introduce the necessary code in the relevant place.
-
- May 29, 2018
-
-
Boris Feld authored
It is useful for a version of shelve not based on bundle and strip. Having more data does not hurt the bundle based case so we introduce it in all cases before doing more rework. We also keep storing the patch using another method. note: We could have this metadata file list all the file involved in the shelve and use that for cleanup. This would be more future proof than having a hard-coded list of file to purge. However, this is an adventure for another series.
-
- Aug 05, 2018
-
-
Yuya Nishihara authored
It's hidden since I'm not sure if filectx templates can be a thing. The plan is to add {status}, {size}, etc., which are usable within {files % ...} context.
-
Yuya Nishihara authored
.. bc:: ``{copy}`` in status command template is renamed to ``{source}``.
-
Yuya Nishihara authored
Note that {path} in status is either relative-to-cwd or repository-absolute depending on the command argument and config knob, which can't be reproduced by using the {path|relpath} filter. The default template is updated to always use a relative path. .. bc:: ``{abspath}`` and ``{file}`` in generic templates are renamed to ``{path}``. Any ``{path}`` is a repository-absolute path. Use ``{path|relpath}`` to convert it to a filesystem path.
-
Yuya Nishihara authored
For the same reason as the previous patch. We might want some hack to support {source.path}, {source.rev}, etc., but that's a different issue.
-
Yuya Nishihara authored
This is a part of the name unification. All {path}s will be changed to repository-absolute (i.e. canonical) paths. https://www.mercurial-scm.org/wiki/GenericTemplatingPlan#Dictionary
-
- Aug 29, 2018
-
-
Pulkit Goyal authored
Few months ago or maybe a year ago, I imported Fb's heuristics based copytracing algorithms. While importing that, I renamed `experimental.disablecopytrace` with `experimental.copytrace` and the behavior of the new config option was like this: * "heuristics" : Fb's heuristic copytracing algorithm * "off" : copytracing is turned off * something else: copytracing is on This is the behavior right now also and this is bad because it hardcodes the string 'off' to turn off the copytracing. On big repositories, copytracing is very slow and people wants to turn copytracing off. However if the user sets it to 'False', 'Off', '0', none of them is going to disbale copytracing while they should. I lacked the understanding of why this can be bad when I coded it. After this patch, the new behavior of the config option will be: * "heuristics": Fb's heuristic copytracing algorithm * '0', 'false', 'off', 'never', 'no', 'NO', all the values which repo.ui.configbool() evaluates to False: copytracing in turned off * something else: copytracing is on Since 'off' still evaluates to copytracing being turned off, this is not BC. Also the config option is experimental. Differential Revision: https://phab.mercurial-scm.org/D4416
-
- Aug 30, 2018
-
-
Pulkit Goyal authored
Last night, when I was working on different machine, the test worked, now on a different machine it does not. Looks like we should make sure releasenotes extension is loaded. Differential Revision: https://phab.mercurial-scm.org/D4425
-
Pulkit Goyal authored
The function is renamed to getbundlechangegrouppart_widen as per suggestion in D4383. The motivation is such that we can evolve the function into a handler for new wire-protocol command. Differential Revision: https://phab.mercurial-scm.org/D4424
-
Pulkit Goyal authored
The test is renamed to test-narrow-widen-no-ellipsis (note non -> no), to match with test-narrow-clone-no-ellipsis.t. Follows up on D4382. Differential Revision: https://phab.mercurial-scm.org/D4423
-
- Aug 29, 2018
-
-
Pulkit Goyal authored
This is done using contrib/byteify-strings.py. There is just one extra change done to make sure lines don't get longer than 80 chars. # skip-blame because just b'' prefixes. Differential Revision: https://phab.mercurial-scm.org/D4422
-
Martin von Zweigbergk authored
I think we used {node|short} because they were first written for only flat manifests and we didn't think to change the format when we started testing tree manifests. Differential Revision: https://phab.mercurial-scm.org/D4421
-
Martin von Zweigbergk authored
Revision "5" is an unambiguous hex prefix in a repo with 5 revisions; it's only "4" and lower that are ambiguous. Differential Revision: https://phab.mercurial-scm.org/D4420
-
- Aug 30, 2018
-
-
Matt Harbison authored
-
- Aug 27, 2018
-
-
Pulkit Goyal authored
We had this test with tree manifest only because the tests were broken and we were fixing them and maintaing two different cases of broken tests was bit hard. Now that things work fine, let's add the flat manifest case. The test shows that things work fine in both cases. Differential Revision: https://phab.mercurial-scm.org/D4385
-
Pulkit Goyal authored
The ellipsis case updates the new narrowspecs at bundle2 handling code, and non-ellipsis widening didn't use to work and never set the new narrowpats. Previous pacth added server side logic for widening without ellipsis. This patch adds the missing repo.setnarrowpats() so that we set the new narrowpats after widening in non-ellipsis cases also. This makes widening with non-ellipsis case work but there are certain things which we can improve. Differential Revision: https://phab.mercurial-scm.org/D4384
-
- Aug 26, 2018
-
-
Pulkit Goyal authored
Before this patch, if you try to widen a narrow clone without ellipsis enabled, it will be broken and the exchange.pull() done by tracked command to widen the clone will be no-op because no custom logic exists for this and server sees that we have all csets and it says `no changes found`. The widening with ellipsis send KILL for existing changegroups and send new changegroups because of the change in ellipsis hash, but we can prevent that in non-ellipsis cases. This patch adds server side logic to send the changegroups for the changesets which are on the client again with filelogs and manifests for the new includes. This is a very starting implementation and we send changegroups and manifests too while we can prevent them. Following things can definitely be improved in the logic this patch adds: 1) Send just the filelogs and treemanifests 2) Send the filelogs only for the additions in the include I tried 1) here but the code is coupled tightly and the way I was able to do that was hacking into the changegroup generation code in a very dirty way, like adding conditionals and preventing the yield. This patch also adds a 'widen' kwarg to prevent other commands except widening to go through that codepath. The test changes demonstrate that the new implementation is correct and fixes things. Differential Revision: https://phab.mercurial-scm.org/D4383
-
- Aug 27, 2018
-
-
Pulkit Goyal authored
This patch adds a test to show that widening a narrow clone is broken if ellipsis is disabled. I don't think I can add cases to existing test-narrow-widen.t and check-in a failing version of that. So I created a copy. Once the test is fixed, we can merge this new test file back into the original one using testcases. Also, this is just testing treemanifest case because having two cases and both or are failing with different outputs is a bit hard to manage. This is important because upcoming patches will try to fix the broken part. Differential Revision: https://phab.mercurial-scm.org/D4382
-
Gregory Szorc authored
This avoids concatenating output inside pprintgen() itself. But the real reason for this is it will make it easier to add indentation, as we'll need to account for indentation when emitting each individual object in a collection. The verbosity of this code compared to the original is a bit unfortunate. But I suppose this is the price to pay for having nice things (streaming and indenting). We could probably abstract the "print a collection" bits into a generic function to avoid some duplication. But I'm not overly inclined to do this. Differential Revision: https://phab.mercurial-scm.org/D4398
-
Gregory Szorc authored
This commit splits the core of pprint() to a new function that is a generator of chunks instead of a function returning a single value. This will make it possible to stream output without waiting for all data to be formatted first. And it will make it easier to implement support for indenting. Differential Revision: https://phab.mercurial-scm.org/D4397
-
- Jul 25, 2018
-
-
Augie Fackler authored
I figure this makes more sense to keep in the main repo, as it's a guide of sorts on how to use the releasenotes extension in the presence of commits that don't get relnotes annotations. Ported to Python 3, cleaned up some logic in a few places, but for the most part it's what we've been using for years. Differential Revision: https://phab.mercurial-scm.org/D4291
-
Augie Fackler authored
We're starting to write new utility scripts in Python 3, and I think it's reasonable to expect `python3` to be something we should use if it's present. I wrote the regex to specifically ban Python 3 prior to Python 3.5 because we won't ever support that. I moved the only test that was using $PYTHON3 to just using `python3` directly. Differential Revision: https://phab.mercurial-scm.org/D4290
-
- Aug 29, 2018
-
-
Martin von Zweigbergk authored
Ever since 447ea621e50e (copy: propagate errors properly, 2007-12-06), we have returned an error status if the source file did not exist. That commit did not return error status for any other errors, and it's unclear if that was on purpose or not. It seems to me like we should return an error in the other cases to, so that's what this patch does. Differential Revision: https://phab.mercurial-scm.org/D4419
-
Martin von Zweigbergk authored
Both the code and the message for the case where the source file was missing was inconsistent with the other similar messages. Differential Revision: https://phab.mercurial-scm.org/D4418
-
Martin von Zweigbergk authored
I think we usally use single quotes around hg commands in messages. Differential Revision: https://phab.mercurial-scm.org/D4417
-
- Aug 21, 2018
-
-
Anton Shestakov authored
Differential Revision: https://phab.mercurial-scm.org/D4361
-
Anton Shestakov authored
addremove, remove and serve accept -S/--subrepos, and purge actually doesn't. qnew accepts -I/--include and -X/--exclude. qrefresh accepts -D/--currentdate, -U/--currentuser, -d/--date and -u/--user. rebase accepts -n/--dry-run. Differential Revision: https://phab.mercurial-scm.org/D4360
-
- Aug 26, 2018
-
-
sliquister authored
Differential Revision: https://phab.mercurial-scm.org/D4377
-
- Jun 05, 2018
-
-
Boris Feld authored
Core shelve extension does not use obsolescence, we clean up this unused file before adding a new info file.
-
- May 29, 2018
-
-
Boris Feld authored
There are no user of this code nor any code related to obsshelve in the extensions right now, so we rename the function before using them. Note: The shelvedfile looks a bit strange. We should probably refactor it, however, this is an adventure for another series.
-
- Aug 22, 2018
-
-
Boris Feld authored
It is simpler not to have to jump around the file all the time.
-
- Aug 05, 2018
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
-
Yuya Nishihara authored
A subtopic is no longer lowercased since it should be considered a part of a topic path, not a section filter.
-
Yuya Nishihara authored
-
- Aug 18, 2018
-
-
Boris Feld authored
Now all "simple" filtering logic is gathered in one place. The `finddeltainfo` method is more straightforward and the `_candidate_groups` function knows more about filtering revisions before we compute a delta against them.
-