- Jul 05, 2017
-
-
Augie Fackler authored
-
- Jul 01, 2017
-
-
Pierre-Yves David authored
This make is simpler to edit the extensions file without side effect.
-
Pierre-Yves David authored
This makes each test boundaries clearer.
-
- Jun 28, 2017
-
-
Pierre-Yves David authored
This is a first basic visible usage of the changes tracking in the transaction. We adds a new function computing the pre-existing changesets obsoleted by a transaction and a transaction call back displaying this information. Example output: added 1 changesets with 1 changes to 1 files (+1 heads) 3 new obsolescence markers obsoleted 1 changesets The goal is to evolve the transaction summary into something bigger, gathering existing output there and adding new useful one. This patch is a good first step on this road. The new output is basic but give a user to the content of tr.changes['obsmarkers'] and give an idea of the new options we haves. I expect to revisit the message soon. The caller recording the transaction summary should also be moved into a more generic location but further refactoring is needed before it can happen.
-
- Jul 02, 2017
-
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
Repository cloned-bookmark-default and tobundle exist in the working directory of main test repository "repo". We should take care for them, because it is known issue that fsmonitor can't handle nested repositories. These nested repositories are cloned from "repo", and the number of unknown files = files in these repositories (including files under .hg) will be changed easily in the future. But testing with fsmonitor is not ordinary. Therefore, test-bookmarks.t with fsmonitor might be broken silently. This is reason why this patch uses "(glob)" for the number of unknown files in "hg summary" output. BTW, this patch doesn't use .hgignore to make test portable, because .hgignore might cause another issue related to "walk_on_invalidate" configuration of fsmonitor.
-
Katsunori FUJIWARA authored
Temporarily enabling largefiles causes these output lines, only if tests are executed with fsmonitor.
-
- Jul 04, 2017
-
-
Gregory Szorc authored
'.' is "working directory parent" not "working directory."
-
- Jun 23, 2017
-
-
Pierre-Yves David authored
The general delta heuristic to select a delta do not scale with the number of branch. The delta base is frequently too far away to be able to reuse a chain according to the "distance" criteria. This leads to insertion of larger delta (or even full text) that themselves push the bases for the next delta further away leading to more large deltas and full texts. This full text and frequent recomputation throw Mercurial performance in disarray. For example of a slightly large repository 280 000 files (2 150 000 versions) 430 000 changesets (10 000 topological heads) Number below compares repository with and without the distance criteria: manifest size: with: 21.4 GB without: 0.3 GB store size: with: 28.7 GB without 7.4 GB bundle last 15 00 revisions: with: 800 seconds 971 MB without: 50 seconds 73 MB unbundle time (of the last 15K revisions): with: 1150 seconds (~19 minutes) without: 35 seconds Similar issues has been observed in other repositories. Adding a new option or "feature" on stable is uncommon. However, given that this issues is making Mercurial practically unusable, I'm exceptionally targeting this patch for stable. What is actually needed is a full rework of the delta building and reading logic. However, that will be a longer process and churn not suitable for stable. In the meantime, we introduces a quick and dirty mitigation of this in the 'experimental' config space. The new option introduces a way to set the maximum amount of memory usable to store a diff in memory. This extend the ability for Mercurial to create chains without removing all safe guard regarding memory access. The option should be phased out when core has a more proper solution available. Setting the limit to '0' remove all limits, setting it to '-1' use the default limit (textsize x 4).
-
- Jul 02, 2017
-
-
Yuya Nishihara authored
The bundled hg should work flawlessly in most cases. Make it depend on the external installation only if necessary since we can't control the whole environment. This patch doesn't implement the "exit 80" idea proposed by Jun. I don't want to keep the capability checking sync with the actual tests.
-
Yuya Nishihara authored
It's simple and works well unless you are using third-party extensions that changes the store format.
-
Yuya Nishihara authored
-
- Jun 30, 2017
-
-
Yuya Nishihara authored
Since os.environ may be overridden in run-tests.py, several important variables such as PATH weren't restored. I don't like the idea of using the system hg *by default* because the executable and the configs are out of our control. But I don't mind as long as the tests pass.
-
- Jul 02, 2017
-
-
Gregory Szorc authored
People often want to know what they are working on *now*. As part of this, they also commonly want to know how that work is related to other changesets in the repo so they can perform common actions like rebase, histedit, and merge. `hg show work` made headway into this space. However, it is geared towards a complete repo view as opposed to just the current line of work. If you have a lot of in-flight work or the repo has many heads, the output can be overwhelming. The closest thing Mercurial has to "show me the current thing I'm working on" that doesn't require custom revsets is `hg qseries`. And this requires MQ, which completely changes workflows and repository behavior and has horrible performance on large repos. But as sub-optimal as MQ is, it does some things right, such as expose a model of the repo that is easy for people to reason about. This simplicity is why I think a lot of people prefer to use MQ, despite its shortcomings. One common development workflow is to author a series of linear changesets, using bookmarks, branches, anonymous heads, or even topics (3rd party extension). I'll call this a "stack." You periodically rewrite history in place (using `hg histedit`) and reparent the stack against newer changesets (using `hg rebase`). This workflow can be difficult because there is no obvious way to quickly see the current "stack" nor its relation to other changesets. Figuring out arguments to `hg rebase` can be difficult and may require highlighting and pasting multiple changeset nodes to construct a command. The goal of this commit is to make stack based workflows simpler by exposing a view of the current stack and its relationship to other releant changesets, notably the parent of the base changeset in the stack and newer heads that the stack could be rebased or merged into. Introduced is the `hg show stack` view. Essentially, it finds all mutable changesets from the working directory revision in both directions, stopping at a merge or branch point. This limits the revisions to a DAG linear range. The stack is rendered as a concise list of changesets. Alongside the stack is a visualization of the DAG, similar to `hg log -G`. Newer public heads from the branch point of the stack are rendered above the stack. The presence of these heads helps people understand the DAG model and the relationship between the stack and changes made since the branch point of that stack. If the "rebase" command is available, a `hg rebase` command is printed for each head so a user can perform a simple copy and paste to perform a rebase. This view is alpha quality. There are tons of TODOs documented inline. But I think it is good enough for a first iteration.
-
- Jun 29, 2017
-
-
Matt Harbison authored
Not only is the output of these commands inconsistent with respect to each other when a file is deleted, they are internally inconsistent depending upon whether the deleted file is in the top level repo or a subrepo. It seemed easier to show the problems, rather than describe them. The original goal was to fix the summary command with respect to deleted files. I haven't fixed any of the other issues yet, in case anybody believes the current subrepo behavior is correct. I think a natural understanding of clean/dirty is that they are two opposite values of a single binary repo state. If `hg update --clean -r .` changes a file, then naturally that repo was dirty, and `hg update --check` should have blocked it. Deleted files are special, in that they don't block a commit. But they make the filesystem content not the same as a clean checkout.
-
- Jul 02, 2017
-
-
Gregory Szorc authored
The ignore regular expression has been updated to detect "inconsistent config." If present, we track which configs have that set and we suppress the conflicting defaults error for those options. I also added named groups to the regexp to aid readability. A comment was added to profiling.py to make a desired inconsistent value error go away.
-
- Jun 30, 2017
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
- Jul 01, 2017
-
-
Matt Harbison authored
External hooks end up launching cmd.exe, which knows nothing about $VAR syntax. For some reason, I thought that Mercurial would substitute in the value, in order to paper over the platform difference. But I can't find that in the documentation, and there's at least one other use of this pattern [1]. [1] https://www.mercurial-scm.org/repo/hg/file/tip/tests/test-histedit-fold.t#l477
-
Martin von Zweigbergk authored
I suspect Jun wrote the method before he learnt that Python 2.7 allows multiple context managers in a single with-clause.
-
- Jul 04, 2017
-
-
Augie Fackler authored
We'll move this to the default branch.
-
- Jun 26, 2017
-
-
Boris Feld authored
Extensions sometimes wants to add other information in the default log output format (when no templating is used). Add an empty function named '_exthook' for easing the extension life. Extensions will be able to wrap this function and collaborate to display additional information. Exthook is called after displaying troubles and just before displaying the files, extra and description. Add a new test file to test it and not pollute other test files.
-
- Jun 27, 2017
-
-
Jun Wu authored
This patch adds special comment handling so one can create obsmarkers in drawdag comments like "# replace: A -> B -> C", "# prune: X, Y, Z", "split: P -> M, N" and they are just self-explained.
-
Jun Wu authored
The drawdag script is useful but does not have a formal test. This patch adds it.
-
- Jun 23, 2017
-
-
Pierre-Yves David authored
The general delta heuristic to select a delta do not scale with the number of branch. The delta base is frequently too far away to be able to reuse a chain according to the "distance" criteria. This leads to insertion of larger delta (or even full text) that themselves push the bases for the next delta further away leading to more large deltas and full texts. This full text and frequent recomputation throw Mercurial performance in disarray. For example of a slightly large repository 280 000 files (2 150 000 versions) 430 000 changesets (10 000 topological heads) Number below compares repository with and without the distance criteria: manifest size: with: 21.4 GB without: 0.3 GB store size: with: 28.7 GB without 7.4 GB bundle last 15 00 revisions: with: 800 seconds 971 MB without: 50 seconds 73 MB unbundle time (of the last 15K revisions): with: 1150 seconds (~19 minutes) without: 35 seconds Similar issues has been observed in other repositories. Adding a new option or "feature" on stable is uncommon. However, given that this issues is making Mercurial practically unusable, I'm exceptionally targeting this patch for stable. What is actually needed is a full rework of the delta building and reading logic. However, that will be a longer process and churn not suitable for stable. In the meantime, we introduces a quick and dirty mitigation of this in the 'experimental' config space. The new option introduces a way to set the maximum amount of memory usable to store a diff in memory. This extend the ability for Mercurial to create chains without removing all safe guard regarding memory access. The option should be phased out when core has a more proper solution available. Setting the limit to '0' remove all limits, setting it to '-1' use the default limit (textsize x 4).
-
- 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
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).
-
- 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.
-