- Jun 28, 2019
-
-
Navaneeth Suresh authored
Until now, `shelve` was bootstrapped as an extension. This patch adds `shelve` on core. Differential Revision: https://phab.mercurial-scm.org/D6553
-
- Nov 12, 2018
-
-
Boris Feld authored
Now that sparse-revlog is enabled by default, we no longer needs it. Differential Revision: https://phab.mercurial-scm.org/D5346
-
Boris Feld authored
We are about to enable sparse-revlog globally. To help with reviewing the tests change, we isolate them in individual changesets. Differential Revision: https://phab.mercurial-scm.org/D5340
-
- Sep 17, 2018
-
-
Anton Shestakov authored
Support for bundle2 streaming clones has been shipped in Mercurial 4.5 (7eedbd5d4880), but was never activated by default. It's time to have more people use it. The new format allows streaming clones to transport cache (hooray for speed) and phaseroots (fixes phase-related issues). Changes in tests: bundle2 capabilities now have "stream=v2" (plus a '\n' as a separator) and therefore take 14 bytes more: "%0Astream%3Dv2". Tip for tests that have data encoded with CBOR: 0xd3 - 0xc5 = 14. $USUAL_BUNDLE2_CAPS$ replaces $USUAL_BUNDLE2_CAPS_SERVER$, which is the same thing, but without "stream=v2". Since streaming clones now also transfer caches, the reported byte and file counts are higher (e.g. 816 bytes in 9 files instead of 613 bytes in 4 files, a bit of --debug and manual math confirms that the caches take these extra 203 bytes in 5 files). Differential Revision: https://phab.mercurial-scm.org/D4680
-
- Sep 19, 2018
-
-
Matt Harbison authored
Python3 defaults to installing under "Program Files".
-
- Sep 04, 2018
-
-
Meirambek Omyrzak authored
output before: "500 files, 2035 changesets, 2622 total revisions" output after: "checked 2035 changesets with 2622 changes to 500 files" new one was suggested in the comments inside the issue. Differential Revision: https://phab.mercurial-scm.org/D4476
-
- Aug 29, 2018
-
-
Boris Feld authored
When interacting with non-publishing repository or bundle, it is useful to have some information about the phase of the changeset we just pulled. This changeset updates the "new changesets MIN:MAX" output to also includes phases information for non-public changesets. Displaying extra data about non-public changesets means the output for exchange with publishing repository (the default) is unaffected.
-
- May 01, 2018
-
-
Gregory Szorc authored
The killdaemons hghave feature has returned True since it was introduced in 448d0c452140. As such, "#require killdaemons" has no effect and is superfluous. So we remove instances of it. Differential Revision: https://phab.mercurial-scm.org/D3442
-
- Apr 05, 2018
-
-
Gregory Szorc authored
Parts of the test were assuming the use of revlogs with fnstore path encoding. Other parts of the test assumed we could create repos with different store encodings and that stream clone bundles worked. Make all of this conditional on running a revlog repo. Differential Revision: https://phab.mercurial-scm.org/D3112
-
- Apr 04, 2018
-
-
Gregory Szorc authored
Before, we used the default store, which was based on fncache and dotencode. After attempting to port tests to work with the simple store, I realized that fncache was more trouble than it is worth. This commit implements a proper store type for the simple repo - one that isn't based off fncache. This causes a number of new test failures because of tests expecting the full fncache store filename encoding. I may extend the store format in a subsequent commit to take the filename encoding parts of fncache that we can take (basically everything except hash encoding, since that isn't reversible). But for now, let's use encoded store. As part of this, we implement proper requirements support for repos created with the simple store. This should have been done from the beginning, as a requirement is needed to lock out clients that don't understand a storage format. A new hghave feature advertising the presence of fncache in repos has been added. Most tests touching the fncache are now conditional on that feature. Other tests have added the optional repo requirement to output. Differential Revision: https://phab.mercurial-scm.org/D3095
-
Gregory Szorc authored
Not all stores may be backed by revlogs. Switch to a more generic error message. Differential Revision: https://phab.mercurial-scm.org/D3094
-
Gregory Szorc authored
bundlerepo is... going to be difficult to port to an alternate store because it assumes revlogs for storage and essentially overlays the contents of a bundle onto a fake revlog-like primitive. It will be a good test case for our eventual new storage interface. Refactoring bundlerepo to make it work with non-revlog storage is going to be a bit of work. So for now, let's refuse to use the simple store repo when a bundlerepo is in play. A new test requirement advertising support for treating bundle files as repo instances has been added. Some tests have been made conditional on this feature. Additional tests will be annotated in subsequent commits. Having positive opt-in to repo features will be simpler in the long run because it will allow multiple storage backends to declare feature support and we won't have to annotate each test with the set of repo backends that are supported. Again, we'll probably want better integration between repo features and tests. But this is the easiest we can do at the moment. Differential Revision: https://phab.mercurial-scm.org/D3060
-
- Apr 03, 2018
-
-
Gregory Szorc authored
`hg pull <bundle>` uses the special "bundlerepo" repository. The bundlerepo code makes many assumptions about the storage of repositories. It will be difficult to teach bundlerepo to use non-revlog storage before a better storage interface is established. Many test failures using our "simple store" are related to bundlerepo: the simple store just isn't compatible with bundlerepo because of storage assumptions in bundlerepo. In order to mitigate the impact of bundlerepo on our code base, this commit changes various tests to use `hg unbundle` instead of `hg pull`. This bypasses the bundlerepo code. Tests exercising exchange functionality have not been altered, as they should be using `hg pull` and going through the bundlerepo code paths. Differential Revision: https://phab.mercurial-scm.org/D3059
-
- Apr 04, 2018
-
-
Gregory Szorc authored
format.usegeneraldelta defaults to true. Differential Revision: https://phab.mercurial-scm.org/D3057
-
- Apr 02, 2018
-
-
Gregory Szorc authored
These fields are an implementation detail of revlog storage. As such, they are not part of the generic storage "index" interface and shouldn't be displayed by default. Because we don't have another way to display these fields, we've retained support for printing these fields via --verbose. Yes, I know we should probably be doing all this formatting using modern formatting/templater APIs. I didn't feel like scope bloating this patch. Differential Revision: https://phab.mercurial-scm.org/D3028
-
Gregory Szorc authored
Revlog index data consists of generic index metadata that will likely be implemented across all storage engines and revlog-specifc metadata. Most tests printing index data only care about the generic fields. This commit drops the printing of the base revision from `hg debugindex`. This value is an implementation detail of revlogs / delta chains. If tests are interested in verifying this implementation detail, `hg debugdeltachain` is a better command. Most tests were skipping over this field anyway. Tests that weren't looked like they were newer. So my guess is we forgot to make them skip the field to match the style of the older tests. This reinforces my belief that the base revision is not worth having in `hg debugindex`. Differential Revision: https://phab.mercurial-scm.org/D3027
-
- Dec 11, 2017
-
-
Matt Harbison authored
# skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
-
- Oct 12, 2017
-
-
Denis Laxalde authored
Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
-
- Oct 01, 2017
-
-
Gregory Szorc authored
--uncompressed isn't a very good name and its description in the help documentation isn't very useful. We refer to this concept as "stream clones" in a number of places. I think it makes sense to change the user-facing argument to use the mode --stream. So this commit does that. We keep --uncompressed around for backwards compatibility. While we're here, we overhaul the help docs for streaming clones to be somewhat useful. All tests have been updated to reflect the new preferred --stream argument. A test for backwards compatibility of --uncompressed has been added. .. bc:: `hg clone --stream` should now be used instead of --uncompressed. --uncompressed is marked as deprecated and is an alias for --stream. There is no schedule for elimination of --uncompressed. Differential Revision: https://phab.mercurial-scm.org/D864
-
- Sep 01, 2017
-
-
Saurabh Singh authored
There was an extra commit made during the amend operation to track the changes to the working copy. However, this logic was written a long time back and newer API's make this extra commit redundant. Therefore, I am removing the extra commit. After this change, I noticed that - Execution time of the cmdutil.amend improved by over 40%. - Execution time of "hg commit --amend" improved by over 20%. Test Plan: I ensured that the all the hg tests passed after the change. I had to fix a few tests which were aware of the extra commit made during the amend. Differential Revision: https://phab.mercurial-scm.org/D636
-
- Jun 26, 2017
-
-
Jun Wu authored
This is marked as BC because the strip backup file name has changed.
-
- Jun 20, 2017
-
-
Augie Fackler authored
This time ones that are prefixed with =, ", ', or `. This appears to be the last of them. Differential Revision: https://phab.mercurial-scm.org/D14
-
- Mar 02, 2017
-
-
Durham Goode authored
In a flat manifest, a node with the same content but different parents is still considered a new node. In the current tree manifests however, if the content is the same, we ignore the parents entirely and just reuse the existing node. In our external treemanifest extension, we want to allow having one treemanifest for every flat manifests, as a way of easeing the migration to treemanifests. To make this possible, let's change the root node treemanifest behavior to match the behavior for flat manifests, so we can have a 1:1 relationship. While this sounds like a BC breakage, it's not actually a state users can normally get in because: A) you can't make empty commits, and B) even if you try to make an empty commit (by making a commit then amending it's changes away), the higher level commit logic in localrepo.commitctx() forces the commit to use the original p1 manifest node if no files were changed. So this would only affect extensions and automation that reached passed the normal localrepo.commit() logic straight into the manifest logic.
-
- Mar 08, 2017
-
-
Durham Goode authored
Previously the hg files tests also covered the logic (i.e. treemanifest.matches) that governed how hg diff limited its diff. In a future patch we will be switching treemanifest.diff() to have a custom implementation, so let's go ahead and add equivalent test coverage for hg diff.
-
- Nov 30, 2016
-
-
Jun Wu authored
The POSIX documentation about "cp" [1] says: .... RATIONALE .... Earlier versions of this standard included support for the -r option to copy file hierarchies. The -r option is historical practice on BSD and BSD-derived systems. This option is no longer specified by POSIX.1-2008 but may be present in some implementations. The -R option was added as a close synonym to the -r option, selected for consistency with all other options in this volume of POSIX.1-2008 that do recursive directory descent. The difference between -R and the removed -r option is in the treatment by cp of file types other than regular and directory. It was implementation-defined how the - option treated special files to allow both historical implementations and those that chose to support -r with the same abilities as -R defined by this volume of POSIX.1-2008. The original -r flag, for historic reasons, did not handle special files any differently from regular files, but always read the file and copied its contents. This had obvious problems in the presence of special file types; for example, character devices, FIFOs, and sockets. .... .... Issue 6 The -r option is marked obsolescent. .... Issue 7 .... The obsolescent -r option is removed. .... (No "Issue 8" yet) Therefore it's clear that "cp -R" is strictly better than "cp -r". The issue was discovered when running tests on OS X after 0d87b1caed92. [1]: pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
-
- Aug 05, 2016
-
-
Augie Fackler authored
This is a little messier than I'd like, and I'll probably come back and do some more refactoring later, but as it is this unblocks narrowhg. An alternative approach (which I may do as part of the mentioned refactoring) would be to construct *all* dirlog instances up front, so that we don't have to keep track of the linkmapper method. This would avoid a reference cycle between the bundlemanifest and the bundlerepository, but I was hesitant to do all the work up front like that. With this change, it's possible to do 'hg incoming' and 'hg pull' from bundles in .hg/strip-backup in a treemanifest repository. Sadly, this doesn't make it possible to 'hg clone' one of those (if you do 'hg strip 0'), because the cg3 in the bundle gets written without a treemanifest flag. Since that's going to be an involved refactor in a different part of the code (which I *suspect* won't touch any of the code I've just written here), let's leave it as an idea for Later.
-
- Jul 28, 2016
-
-
Augie Fackler authored
I realized we weren't testing this while hunting a broken manifest command bug that ended up being narrowhg's fault.
-
- Jun 30, 2016
-
-
Martin von Zweigbergk authored
Stripping has only partly worked since 7cbb3a01fa38 (repair: use cg3 for treemanifests, 2016-01-19): the bundle seems to have been created correctly, but revlog entries in subdirectory revlogs were not stripped. This meant that e.g. "hg verify" would fail after stripping in a tree manifest repo. To find the revisions to strip, we simply iterate over all directories in the repo (included in store.datafiles()). This is inefficient for stripping few commits, but efficient for stripping many commits. To optimize for stripping few commits, we could instead walk the tree from the root and find modified subdirectories, just like we do in the changegroup code. I'm leaving that for another day.
-
- Jun 16, 2016
-
-
Martin von Zweigbergk authored
When grafting/rebasing, it is common for multiple changesets to make the same change to a subdirectory. When writing the revlog for the directory, the revlog code already takes care of not writing the entry again. In 0c2a088ffcc5 (changegroup: prune subdirectory dirlogs too, 2016-02-12), I added the corresponding code in changegroup (not sending entries the client already has), but I forgot to avoid sending the entire changegroup if no nodes remained in the pruned set. Although that's harmless besides the wasted network traffic, the receiving side was checking for it (copied from the changegroup code for handling files). This resulted in the client crashing with: abort: received dir revlog group is empty Fix by simply not emitting a changegroup for the directory if there were no changes is it. This matches how files are handled.
-
- Mar 26, 2016
-
-
Martin von Zweigbergk authored
When using treemanifests, only changegroup3 bundles can be created. However, there is currently no way of requesting a changegroup3 bundle, so we run into an assertion in changegroup.getbundler() when trying to get a changroup2 bundler. Let's avoid the traceback and print a short error message instead.
-
- Mar 02, 2016
-
-
Danek Duvall authored
The treemanifest tests use the -T option to cp in order to ensure that the two directories named on the commandline are treated as peers, rather than the usual behavior when the final argument is a directory. GNU cp has this option, but other implementations may not. Thankfully, there's no pressing reason to use it. We can simply copy the contents of the first directory into the target directory, since we know that the target directory already exists.
-
- Feb 13, 2016
-
-
Martin von Zweigbergk authored
The current code for generating treemanifest revisions takes the list of files in the changeset and finds the directories from them. This does not work for merges, since a merge may pick file A from one side and file B from another and neither of them would appear in the changeset's "files" list, but the manifest would still change. Fix this by instead walking the root manifest log for all needed revisions, storing all needed file and subdirectory revisions, then recursively visiting the subdirectories. This also turns out to be faster: cloning a version of hg core converted to treemanifests went from ~28s to ~19s (timing somewhat unfair: before this patch, timed until crash; after this patch, timed until manifests complete). The new algorithm is used only on treemanifest repos. Although it works equally well on flat manifests, we leave the iteration over files in the changeset for flat manifests for now.
-
- Feb 24, 2016
-
-
Tony Tung authored
This is more similar to cp -T because it covers hidden files.
-
- Feb 03, 2016
-
-
Martin von Zweigbergk authored
We already report orphaned filelogs, i.e. revlogs for files that are not mentioned in any manifest. This change adds checking for orphaned dirlogs, i.e. revlogs that are not mentioned in any parent-directory dirlog. Note that, for fncachestore, only files mentioned in the fncache are considered, there's not check for files in .hg/store/meta that are not mentioned in the fncache. This is no different from the current situation for filelogs.
-
- Feb 08, 2016
-
-
Martin von Zweigbergk authored
In repos with treemanifests, there is no specific verification of directory manifest revlogs. It simply collects all file nodes by reading each manifest delta. With treemanifests, that's means calling the manifest._slowreaddelta(). If there are missing revlog entries in a subdirectory revlog, 'hg verify' will simply report the exception that occurred while trying to read the root manifest: manifest@0: reading delta 1700e2e92882: meta/b/00manifest.i@67688a370455: no node This patch changes the verify code to load only the root manifest at first and verify all revisions of it, then verify all revisions of each direct subdirectory, and so on, recursively. The above message becomes b/@0: parent-directory manifest refers to unknown revision 67688a370455 Since the new algorithm reads a single revlog at a time and in order, 'hg verify' on a treemanifest version of the hg core repo goes from ~50s to ~14s. As expected, there is no significant difference on a repo with flat manifests.
-
- Feb 17, 2016
-
-
timeless authored
test-treemanifest.t had introduced HGPORT3 and HGPORT4, which were improperly added to run-tests.py. It also was not using HGPORT1. This recycles HGPORT, and shifts everything into HGPORT1 + HGPORT2.
-
- Feb 11, 2016
-
-
Martijn Pieters authored
The OS X cp implementation has no -T switch. Copy directory contents using a glob instead.
-
- Feb 08, 2016
-
-
Martin von Zweigbergk authored
When I taught debugrebuildfncache about dirlogs in fb92927f9775 (treemanifests: fix streaming clone, 2016-02-04), I added a last-minute "if 'treemanifest' in repo" guard. That should have been checking for "... in repo.requirements". Fix that and add tests for it.
-
- Feb 04, 2016
-
-
Martin von Zweigbergk authored
Similar to the previous patch, the .hg/store/meta/ directory does not get copied when when using "hg clone --uncompressed". Fix by including "meta/" in store.datafiles(). This seems safe to do, as there are only a few users of this method. "hg manifest" already filters the paths by "data/" prefix. The calls from largefiles also seem safe. The use in verify needs updating to prevent it from mistaking dirlogs for orphaned filelogs. That change is included in this patch. Since the dirlogs will now be in the fncache when using fncachestore, let's also update debugrebuildfncache(). That will also allow any existing treemanifest repos to get their dirlogs into the fncache. Also update test-treemanifest.t to use an a directory name that requires dot-encoding and uppercase-encoding so we test that the path encoding works.
-
- Feb 03, 2016
-
-
Martin von Zweigbergk authored
When doing a local clone with treemanifests, the .hg/store/meta/ directory currently does not get copied. To fix it, all we need to do is to add it to the list of directories to copy.
-