- Jan 15, 2015
-
-
Angel Ezquerra authored
This change touches every module in which repository.opener was being used, and changes it for the equivalent repository.vfs. This is meant to make it easier to split the repository.vfs into several separate vfs. It should now be possible to remove localrepo.opener.
-
Sean Farley authored
Now that we have the machinary to change the log name and the color label used, let's use that. Tests have been updated accordingly.
-
Sean Farley authored
Previously, there was no way to change the color label used for 'hg log' output. This patch just adds the member to the object, a future patch will change 'hg log' to use this.
-
Sean Farley authored
Previously, there was no way to change the name used for 'hg log' output. This was inconvenient for extensions that want a template name longer than 12 characters (e.g. remotebookmarks) but a different name for 'hg log'. This patch only adds the member to the object, a future patch will update the 'hg log' code.
-
Sean Farley authored
This is just a style change but makes adding new arguments more robust for callers.
-
Sean Farley authored
None of the arguments are truly optional but this makes adding future arguments more robust and perhaps optional.
-
- Jan 16, 2015
-
-
Gregory Szorc authored
Extensions can declare compatibility with Mercurial versions. If an error occurs, Mercurial will attempt to pin blame on an extension that isn't marked as compatible. While all bets are off when it comes to the internal API, my experience has shown that a monthly/patch release of Mercurial has never broken any of the extensions I've written. I think that expecting extensions to declare compatibility with every patch release of Mercurial is asking a bit much and adds little to no value. This patch changes the blame logic from exact version matching to only match on the major and minor Mercurial versions. This means that extensions only need to mark themselves as compatible with the major, quarterly releases and not the monthly ones in order to stay current and avoid what is almost certainly unfair blame. This will mean less work for extension authors and almost certainly fewer false positives in the blame attribution.
-
Gregory Szorc authored
Mercurial doesn't define the 3rd "patch" version field for major releases. Don't use it in tests.
-
Gregory Szorc authored
There was a mountain of text in this file that made reading the tests difficult. Inserting some line breaks greatly improves the situation.
-
- Dec 19, 2014
-
-
Pierre-Yves David authored
The binary format description has always stated that the parttype should be simple, but it was never really enforced. Recent discussions have convinced me we want to keep the part type simple and easy to debug. There is enough extensibility in the rest of the format.
-
- Jan 15, 2015
-
-
Matt Harbison authored
I still get the following diff on Windows 7 with NTFS. I'm not sure if it is expected and we should wildcard the link count, or if something needs to be fixed. @@ -58,7 +58,7 @@ $ ln bar baz $ f bar -n baz -l --hexdump -t --sha1 --lines=9 -B 20 - bar: file, links=2, newer than baz, sha1=612ca68d0305c821750a + bar: file, links=0, newer than baz, sha1=612ca68d0305c821750a\r (esc) 0000: 31 0a 32 0a 33 0a 34 0a 35 0a 36 0a 37 0a 38 0a |1.2.3.4.5.6.7.8.| 0010: 39 0a |9.|
-
- Jan 14, 2015
-
-
Mads Kiilerich authored
Sleep can only travel forward in time, not back.
-
- Jan 15, 2015
-
-
Pierre-Yves David authored
When the manifest revision is stored as a delta against a non-parent revision, '_adjustlinkrev' could miss some file update because it was using the delta only. We now use the 'fastread' method that uses the delta only when it makes sense. A test showcasing on the of possible issue have been added.
-
Matt Mackall authored
-
- Jan 14, 2015
-
-
Mads Kiilerich authored
self._rbcrevslen is used to keep track of the number of good records on disk. It should thus not be updated before the records actually have been written to disk.
-
Mads Kiilerich authored
The cache files are usually append only but will automatically be truncated and recover in exceptional situations. Add a debug notice when such exceptional situations are encountered.
-
Mads Kiilerich authored
The tests that were added with the revision branch cache in 678f53865c68 had suffered from bit rot in the development iterations. They were no longer that "good". Now, the tests are rewritten and reworked to be more readable and maintainable and relevant for the actual implementation. This also utilizes the new 'f' helper tool for keeping an eye the cache files.
-
Mads Kiilerich authored
This tool is like the collection of tools found in a unix environment but are cross platform and stable and suitable for our needs in the test suite. The main reason it is "needed" now is for hexdump of revision branch cache to keep an eye on how it changes and make sure the format is stable. It is a very generic tool that can end up being used a lot in tests, so I gave it very generic name.
-
Mads Kiilerich authored
The testdir is already added to $PYTHONPATH - I think it makes sense and is convenient to add it to $PATH too. The following binaries are invoked from tests using full path with $TESTDIR/ - they can now be used without specifying path: dumbhttp.py dummyssh filterpyflakes.py generate-working-copy-states.py get-with-headers.py hghave histedit-helpers.sh killdaemons.py md5sum.py notcapable printenv.py readlink.py revlog-formatv0.py run-tests.py svn-safe-append.py svnxml.py tinyproxy.py
-
- Jan 12, 2015
-
-
Mike Edgar authored
-
Mike Edgar authored
When receiving a delta via exchange, three possible storage outcomes emerge: 1. The delta is added directly to the revlog. ("fast-path") 2. A freshly-computed delta with a different base is stored. 3. The new revision's fulltext is computed and stored outright. Both (2) and (3) require materializing the full text of the new revision by applying the delta to its base. This is typically followed by a hash check. The new flags argument allows callers to _addrevision to signal that they expect that hash check to fail. We can use this opportunity to verify that expectation. If the hash fails, require the flag be set; if the hash passes, require the flag be unset. Rather than simply eliding the hash check, this approach provides some assurance that the censored flag is not applied to valid revisions. Read more at: http://mercurial.selenic.com/wiki/CensorPlan
-
Mike Edgar authored
For revlog index flags to be useful to other parts of Mercurial, they need to be settable when writing revisions. The current use case for revlog index flags is the censorship feature: http://mercurial.selenic.com/wiki/CensorPlan While the censor flag could be inferred in _addrevision by interrogating the text/delta being added, that would bury the censorship logic and inappropriately couple it to all revision creation.
-
Mike Edgar authored
This flag bit will be used to cheaply signal censorship presence to upper layers (exchange, verify). It indicates that censorship metadata is present but does not attest to the verifiability of that metadata. For the censorship design, see: http://mercurial.selenic.com/wiki/CensorPlan
-
- Jan 11, 2015
-
-
Angel Ezquerra authored
It has been replaced with localrepo.wvfs.
-
- Jan 10, 2015
-
-
Angel Ezquerra authored
It has been replaced with localrepo.svfs.
-
Angel Ezquerra authored
It has been replaced with localrepo.vfs. In the future we may split the vfs into different vfs objects to access different elements of the repository.
-
- Jan 14, 2015
-
-
Augie Fackler authored
Nobody outside sslutil should be using these constants anyway.
-
Augie Fackler authored
Asking for TLSv1 locks us out of TLSv1_2 etc. This is at least less bad. Ideally we'd use ssl.create_default_context(), but that causes more mayhem in the testsuite than I really want to deal with right now.
-
Augie Fackler authored
We really just want to support the newest thing possible, so we may as well consolidate that knowledge into this module. Right now this doesn't change any behavior, but a future change will fix the defaults for Python 2.7.9 so we can use slightly better defaults there (which is the only place it's possible at the moment.)
-
- Jan 07, 2015
-
-
Pierre-Yves David authored
We have been running discovery on unfiltered repository for quite some time. This was aimed at two things: - save some bandwith by prevent the repushing of common but hidden changesets - allow phases changes on secret/hidden changeset on bare push. The cost of this unfiltered discovery combined with evolution is actually really high. Evolution likely create thousand of hidden heads, and the discovery is going to try to discovery if each of them are common or not. For example, pushing from my development mercurial repository implies 17 discovery round-trip. The benefit are rare corner cases while the drawback are massive. So we run the discovery on a filtered repository again. We add some hack to detect remote heads that are known locally and adds them to the common set anyway, so the good behavior of most of the corner case should remains. But this will not work in all cases. This bring my discovery phase back from 17 round-trips to 1 or 2.
-
- Jan 10, 2015
-
-
Katsunori FUJIWARA authored
Before this patch, collisions between alias argument names in the declaration are ignored, and this silently causes unexpected alias evaluation. This patch checks for such collisions, and aborts (or shows a warning) when collisions are detected. This patch doesn't add a test to "test-revset.t", because a doctest is enough to test the collisions detection itself.
-
Katsunori FUJIWARA authored
Before this patch, alias declaration is parsed by string base operations: matching against "^([^(]+)\(([^)]+)\)$" and splitting by ",". This overlooks many syntax errors like below (see the previous patch introducing "_parsealiasdecl" for detail): - un-closed parenthesis causes being treated as "alias symbol" - symbol/function name aren't examined whether they are valid or not - invalid argument list causes unexpected argument names To parse alias declaration strictly, this patch replaces parsing implementation by "_parsealiasdecl". This patch tests only one typical declaration error case, because error detection itself is already tested in the doctest of "_parsealiasdecl". This also removes class property "args" and "error", because these are certainly initialized in "revsetalias.__init__".
-
Katsunori FUJIWARA authored
This patch introduces "_parsealiasdecl" to parse alias declarations strictly. For example, "_parsealiasdecl" can detect problems below, which current implementation can't. - un-closed parenthesis causes being treated as "alias symbol" because all of declarations not in "func(....)" style are recognized as "alias symbol". for example, "foo($1, $2" is treated as the alias symbol. - alias symbol/function names aren't examined whether they are valid as symbol or not for example, "foo bar" can be treated as the alias symbol, but of course such invalid symbol can't be referred in revset. - just splitting argument list by "," causes overlooking syntax problems in the declaration for example, all of invalid declarations below are overlooked: - foo("bar") => taking one argument named as '"bar"' - foo("unclosed) => taking one argument named as '"unclosed' - foo(bar::baz) => taking one argument named as 'bar::baz' - foo(bar($1)) => taking one argument named as 'bar($1)' To decrease complication of patch, current implementation for alias declarations is replaced by "_parsealiasdecl" in the subsequent patch. This patch just introduces it. This patch defines "_parsealiasdecl" not as a method of "revsetalias" class but as a one of "revset" module, because of ease of testing by doctest. This patch factors some helper functions for "tree" out, because: - direct accessing like "if tree[0] == 'func' and len(tree) > 1" decreases readability - subsequent patch (and also existing code paths, in the future) can use them for readability This patch also factors "_tokenizealias" out, because it can be used also for parsing alias definitions strictly.
-
Katsunori FUJIWARA authored
Before this patch, any errors in the declaration of revset alias aren't detected at all, and there is no information about error source in the error message. As a part of preparation for parsing alias declarations and definitions more strictly, this patch stores full detail into "revsetalias.error" for error source distinction. This makes raising "Abort" and warning potential errors just use "revsetalias.error" without any message composing.
-
Katsunori FUJIWARA authored
This patch defines the composing function not in "ParseError" class but in "revset" module, because: - "_()" shouldn't be used in "ParseError", to avoid adding "from i18n import _" i18n" to "error" module - generalizing message composition of"ParseError" for all code paths other than revset isn't the purpose of this patch we should also take care of showing "unexpected leading whitespace" for some code paths, to generalize widely.
-
Katsunori FUJIWARA authored
Before this patch, "tokenize" doesn't recognize the symbol starting with "$" as a valid one. This prevents revset alias declarations and definitions from being parsed with "tokenize", because "$" may be used as the initial letter of alias arguments. BTW, the alias argument name doesn't require leading "$" itself, in fact. But we have to assume that users may use "$" as the initial letter of argument names in their aliases, because examples in "hg help revsets" uses such names for a long time. To make "tokenize" extensible to parse alias declarations and definitions, this patch introduces optional arguments "syminitletters" and "symletters". Giving these sets can change the policy of "valid symbol" in tokenization easily. This patch keeps original examination of letter validity for reviewability, even though there is redundant interchanging between "chr"/"ord" at initialization of "_syminitletters" and "_symletters". At most 256 times examination (per initialization) is cheaper enough than revset evaluation itself. This patch is a part of preparation for parsing alias declarations and definitions more strictly.
-
- Jan 09, 2015
-
-
Mads Kiilerich authored
'hg update' would hash all 'unsure' largefiles before performing the merge. It would update the standins but not detect the very common case where the largefile never had been changed by the user but just had been marked with an invalid dirstate mtime to make sure any changes done by the user in the same second would be detected. The largefile would remain in that state and would have to be hashed again next time even though it still not had been changed. Sad trombone. Instead, for largefiles listed as 'unsure' or 'modified', after updating the standin with the actual hash, mark the largefile as normal if it turns out to not be modified relative to the revision in the parent revision. That will prevent it from being hashed again next time.
-
Mads Kiilerich authored
The value of the dirstate date field cannot be used in tests and we thus have to use debugdirstate with --nodate. It is however still very helpful to be able to see whether the date field has been set or still is unset. The absence of that information made it hard to debug some largefile dirstate issues. This change _could_ make the test suite more unstable ... but that would be places where the test suite or the code should be made more stable. (Note: 'unset' with the magic negative sizes is reliable. 'unset' for normal sizes would probably not be reliable, but there is no such occurrences in the test suite and it should thus be reliable.) This output wastes more horizontal space in the --nodate output, but it also makes things simpler that the output format always is the same. It is just a debug command so let's keep it simple.
-
Mads Kiilerich authored
-
- Jan 12, 2015
-
-
Matt Harbison authored
It seems like a mistake to report a file as forgotten and rejected. The forgotten list doesn't seem to be used by anything in core, so no test changes.
-