- 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.
-
Martin von Zweigbergk authored
-
- Jan 27, 2016
-
-
Martin von Zweigbergk authored
In c0f11347b107 (changegroup: don't support versions 01 and 02 with treemanifests, 2016-01-19), I stopped supporting use of cg1 and cg2 with treemanifest repos. What I had not considered was that it's perfectly safe to pull *to* a treemanifest repo using any changegroup version. As reported in issue5066, I therefore broke pull from old repos into a treemanifest repo. It was not covered by the test case, because that pulled from a local repo while enabling treemanifests, which enabled treemanifests on the source repo as well. After switching to pulling via HTTP, it breaks. Fix by splitting up changegroup.supportedversions() into supportedincomingversions() and supportedoutgoingversions().
-
- Jan 28, 2016
-
-
Martin von Zweigbergk authored
-
- Jan 27, 2016
-
-
Augie Fackler authored
There were two mistakes: one was accidental reuse of the fclnode variable from the loop gathering file nodes, and the other (masked by that bug) was not correctly handling deleted directories. Both cases are now fixed and the test passes.
-
- Jan 23, 2016
-
-
Martin von Zweigbergk authored
In 5c0fd878779c (treemanifests: set bundle2 part parameter indicating treemanifest, 2016-01-08), I didn't realize I had to set the parameter separately for getbundle and unbundle. Having the parameter there on push allows us to push to an empty repo and have the requirements updated correctly.
-
- Jan 19, 2016
-
-
Martin von Zweigbergk authored
Similar to previous change, this teaches shelve to pick the right changegroup version for repos that use treemanifests.
-
Martin von Zweigbergk authored
The newly created helper changegroup.safeversion() knows to pick version 03 if the repo uses treemanifests, so just using that means we pick the right changegroup version.
-
- Jan 13, 2016
-
-
Martin von Zweigbergk authored
In order to give us the freedom to change the changegroup3 format, let's hide it behind an experimental config. Since it is required by treemanifests, that will override the cg3 config.
-
- Dec 11, 2015
-
-
Augie Fackler authored
I'm not entirely happy with using a trailing / on a "file" entry for transferring a treemanifest. We've discussed putting some flags on each file header[0], but I'm unconvinced that's actually any better: if we were going to add another feature to the cg format we'd still be doing a version bump anyway to cg4, so I'm inclined to not spend time coming up with a more sophisticated format until we actually know what the next feature we want to stuff in a changegroup will be. Test changes outside test-treemanifest.t are only due to the new CG3 bundlecap showing up in the wire protocol. Many thanks to adgar@google.com and martinvonz@google.com for helping me with various odd corners of the changegroup and treemanifest API. 0: It's not hard refactoring, nor is it a lot of work. I'm just disinclined to do speculative work when it's not clear what the customer would actually be.
-