- Jun 26, 2017
-
-
Pierre-Yves David authored
We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.
-
Pierre-Yves David authored
We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.
-
Pierre-Yves David authored
We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.
-
Pierre-Yves David authored
We have a new 'obsutil' module now. We move this high level utility there to bring 'obsolete.py' back to a more reasonable size.
-
- Jun 29, 2017
-
-
Adam Simpkins authored
Update the code to correctly anchor the expression on the end of the name, to require that the entire name match this expression. It was already anchored at the start by using re.match(), but this does not anchor it at the end.
-
Martin von Zweigbergk authored
-
- Jun 28, 2017
-
-
Pierre-Yves David authored
If the remote is empty, we do now bother computing head changes and the 'pushbranchmap' attribute stays at None. We now handle and tests this case.
-
- Jun 26, 2017
-
-
Gregory Szorc authored
As part of using `hg show` in my daily workflow, I've found it slightly annoying to have to type full view names, complete with a space. I've locally registered an alias for "swork = show work." I think others will have this same complaint and could benefit from some automation to streamline the creation of aliases. So, this commit introduces a config option that allows `hg show` views to be automatically aliased using a given prefix. e.g. a value of "s" will automatically register "swork" and "sbookmarks." Multiple values can be given for ultimate flexibility. This arguably isn't needed now. But since we don't register aliases if there will be a collision and we're bound to have a collision, it makes sense to allow multiple prefixes so specific views can avoid collisions by using different prefixes.
-
- Jun 18, 2017
-
-
Pierre-Yves David authored
Now that the default value is also converted we can use a human readable version for it. This will be useful if we start to automatically display the default config value in various place.
-
- Jun 17, 2017
-
-
Pierre-Yves David authored
This exercise the default value handling in 'configbytes'.
-
Pierre-Yves David authored
The version declaration should come first in my opinion. This will help gather the command table with the config table.
-
- Jun 18, 2017
-
-
Pierre-Yves David authored
We do not want such case to pass silently. In the future we'll likely have useful tool for an extension to alter the existing definition in core.
-
- Jun 17, 2017
-
-
Pierre-Yves David authored
Extensions can have a 'configtable' mapping and use 'registrar.configitem(table)' to retrieve the registration function. This behave in the same way as the other way for extensions to register new items (commands, colors, etc).
-
Pierre-Yves David authored
Having the logic available independently from the mapping used is a necessary step toward extensions support.
-
- Jun 18, 2017
-
-
Pierre-Yves David authored
We simplify the unstable computation code, skipping the expensive creation of changectx object. We focus on efficient set operation and revnumber centric functions. In my mercurial development repository, this provides a 3x speedup to the function: before: 5.319 ms after: 1.844 ms repo details: total changesets: 40886 obsolete changesets: 7756 mutable (not obsolete): 293 unstable: 30
-
Pierre-Yves David authored
More obsolescence related algorithm focus on the mutable revision. We provide a tiny utility function to make it easy to access this set.
-
- Jun 27, 2017
-
-
Siddharth Agarwal authored
Seems like the %i was never substituted.
-
Siddharth Agarwal authored
I found this useful while trying to debug wireproto-related issues.
-
- Jun 28, 2017
-
-
Adam Simpkins authored
Update the syshgenv function to attempt to completely restore the original environment, rather than only updating a few specific variables. run_tests.py now generates a shell script that can be used to restore the original environment, and syshgenv sources it. This is a bit more complicated than the previous code, but should do a better job of running the system hg in the correct environment. I've tested it on Linux using python 2.x, but let me know if it causes issues in other environments. I'm not terribly familiar with how the tests get run on Windows, for instance, and how the environment needs to be updated there.
-
Jun Wu authored
Ancient hg does not have "hg files" so test-check-*.t will fail with "unknown command 'files'": $ hg files hg: unknown command 'files' $ hg --version Mercurial Distributed SCM (version 2.6.2) Test "hg files" and give up using syshg if it does not have "files" command.
-
- Jun 27, 2017
-
-
Pierre-Yves David authored
Different hooks will have different properties so we cover more hooks to catch further regressions.
-
Pierre-Yves David authored
Different hooks will have different properties so we cover more hooks to catch further regression.
-
Pierre-Yves David authored
The 4.2 release introduces a regression regarding the behavior of rebase with some hook failures. We add the tests from the bug report from Henrik Stuart to our test base to prevent further regression on this.
-
Pierre-Yves David authored
Having a single transaction for rebase means the whole transaction gets rolled back on error. To work around this a small hack has been added to detect merge conflict and commit the work done so far before exiting. This hack works because there is nothing transaction related going on during the merge phase. However, if a hook blocks the rebase to create a changeset, it is too late to commit the work done in the transaction before the problematic changeset was created. This leads to the whole rebase so far being rolled back. Losing merge resolution and other work in the process. (note: rebase state will be fully lost too). Since issue5610 is a pretty serious regression and the next stable release is a couple day away, we are taking the backout route until we can figure out something better to do.
-
Pierre-Yves David authored
In the process of fixing issue5610 in 4.2.2, we are trying to backout cf8ad0e6c0e4. This changeset is making changes that depend on cf8ad0e6c0e4, so we need to back it out first. Since issue5610 is pretty serious regression and the next stable release is a couple of days away, we are taking the backout route until we can figure out something better to do.
-
- Jun 28, 2017
-
-
Adam Simpkins authored
Fix one invocation of runcmd() that was missed in the recent change to make runcmd() also return the process exit status.
-
- Jun 27, 2017
-
-
Pulkit Goyal authored
We have now 34 tests passing on Python 3.
-
- Jun 28, 2017
-
-
Jun Wu authored
It should return env as a dict instead of None.
-
Adam Simpkins authored
Most test scripts use "hg" to interact with a temporary test repository. However a few tests also want to run hg commands to interact with the local repository containing the mercurial source code. Notably, many of the test-check-* tests want to check local files and commit messages. These tests were previously using the version of hg being tested to query the source repository. However, this will fail if the source repository requires extensions or other settings not supported by the version of mercurial being tested. The source repository was typically initially cloned using the system hg installation, so we should use the system hg installation to query it. There was already a helpers-testrepo.sh script designed to help cope with different requirements for the source repository versus the test repositories. However, it only handled the evolve extension. This new behavior works with any extensions that are different between the system installation and the test installation.
-
Adam Simpkins authored
When running the tests, define ORIG_PATH and ORIG_PYTHONPATH environment variables that contain the original contents of PATH and PYTHONPATH, before they were modified by run-tests.py This will make it possible for tests to refer to the original contents of these variables if necessary. In particular, this is necessary for invoking the correct version of hg for examining the local repository (the mercurial repository itself, not the temporary test repositories). Various tests examine the local repository to check the file lists and contents of commit messages.
-
- Jun 27, 2017
-
-
Adam Simpkins authored
Add a findhg() function that tries to be smarter about figuring out how to run hg for examining the local repository. It first tries running "hg" from the user's PATH, with the default HGRCPATH settings intact, but with HGPLAIN enabled. This will generally use the same version of mercurial and the same settings used to originally clone the repository, and should have a higher chance of working successfully than trying to run the hg script from the local repository. If that fails findhg() falls back to the existing behavior of running the local hg script.
-
Adam Simpkins authored
Replace the runhg() function with an hgcommand helper class. hgcommand has as run() function similar to runhg(), but no longer requires the caller to pass in the exact path to python and the hg script, and the environment settings for invoking hg. For now this diff contains no behavior changes, but in the future this will make it easier for the hgcommand helper class to more intelligently figure out the proper way to invoke hg.
-
- Jun 26, 2017
-
-
Adam Simpkins authored
Add a helper function to compute the environment used for invoking mercurial, rather than doing this computation entirely at global scope. This will make it easier to do some subsequent refactoring.
-
Adam Simpkins authored
Update the runcmd() helper function so it also returns the process exit status. This allows callers to more definitively determine if a command failed, rather than testing only for the presence of data on stderr. I don't expect this to have any behavioral changes for now: the commands invoked by setup generally should print data on stderr if and only if they failed.
-
Adam Simpkins authored
If running hg fails, exit the setup script unsuccessfully, rather than proceeding to use a bogus version of "+0-". Using an invalid version number causes various tests to fail later. Failing early makes it easier to identify the source of the problem. It is currently easy for setup.py to fail this way since it sets HGRCPTH to the empty string before running "hg", which may often disable extensions necessary to interact with the local repository.
-
- Jun 27, 2017
-
-
Yuya Nishihara authored
-
Jun Wu authored
The backup option was mistakenly ignored. It should be respected. Thanks Martin von Zweigbergk for finding this out!
-
- Jun 26, 2017
-
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-