- Mar 03, 2021
-
-
Anton Shestakov authored
-
- Sep 05, 2020
-
-
Sushil Khanchi authored
-
- Aug 26, 2020
-
-
Sushil Khanchi authored
After this change using hg evolve --stop update the working copy parent back to where the working copy was before the hg evolve operation (or the successors of that)
-
- Mar 01, 2021
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
- Feb 27, 2021
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
Let's group import from Mercurial.
-
Anton Shestakov authored
We no longer support 3.8.
-
Pierre-Yves David authored
-
- Feb 23, 2021
-
-
Anton Shestakov authored
-
- Dec 22, 2020
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
We're trying to save users from accidentally losing any content changes if they try to rewind to e.g. only one component of a fold. In such case we're also adding the rest of the components.
-
- Feb 17, 2021
-
-
Anton Shestakov authored
-
- Feb 24, 2021
-
-
Chuck Tuffli authored
Change all instances which describe topics as "disappearing" to the more accurate "fade out" as the information is still available, but no longer used.
-
- Feb 12, 2021
-
-
Chuck Tuffli authored
-
- Feb 22, 2021
-
-
Martin von Zweigbergk authored
-
Martin von Zweigbergk authored
-
- Feb 23, 2021
-
-
Kyle Lippincott authored
Right now, `hg help obslog` says the following, which is a bit confusing: ``` hg olog [OPTION]... [[-r] REV]... aliases: olog ``` Since the primary command name is determined by the order the commands are defined in, and we use 'obslog' as the name for the pager, I've chosen `hg obslog` as the canonical name and am only adjusting the help string.
-
- Feb 22, 2021
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
-
- Feb 17, 2021
-
-
Sushil Khanchi authored
-
- Feb 22, 2021
-
-
Pierre-Yves David authored
-
- Jan 24, 2021
-
-
Pierre-Yves David authored
Because of logic change in divergence resolution which causes the order change in picking the resolution parent this test case was messed up. It was supposed to test that it hits merge conflict while merging the two divergent csets but because of some change in previous patches, we hit conflict early during relocation of one of the cset. This patch, by resolving the conflict for relocation make sure that we test the conflict while merging the two divergent csets.
-
Pierre-Yves David authored
Because of logic change in divergence resolution which causes the order change in picking the resolution parent this test case was messed up. It was supposed to test that that it hits conflict while relocating the divergent cset but because of some change in previous patches, relocation went successful and it hits conflict while merging the two divergent csets. This patch, by making some changes in files content make sure that we get conflict during relocation.
-
Pierre-Yves David authored
Because of logic change in divergence resolution which causes the order change in picking the resolution parent this test case was messed up. It was supposed to test that that it hits conflict while relocating the divergent cset but because of some change in previous patches, relocation went successful and it hits conflict while merging the two divergent csets. This patch, by making some changes in files content make sure that we get conflict during relocation.
-
- Feb 17, 2021
-
-
Sushil Khanchi authored
Now, it is already covered by parent div resolution so removing it.
-
- Feb 18, 2021
-
-
Sushil Khanchi authored
Changes in troubles-handling.rst explains the special case in details and also speak about what is the default behavior and how to change it.
-
- Feb 01, 2021
-
-
Sushil Khanchi authored
-
- Jan 22, 2021
-
-
Sushil Khanchi authored
If the parent were rewritten we need to take them in accound, but to help with resolution of a stack and to have a better 3 way merge. Changes in test file reflect the new behavior.
-
- Jan 28, 2021
-
-
Sushil Khanchi authored
Explained in more details in the test itself. This will be fixed by next patch.
-
- Feb 17, 2021
-
-
Kyle Lippincott authored
When using GENDOC_LOAD_CONFIGURED_EXTENSIONS=1, Mercurial's doc/gendoc.py can load extensions from outside of just the hgext directory, and pull in this doc. When added to the documentation, this should be nested inside of the following extension hierarchy: - Extensions - evolve The generated documentation has an established hierarchy of section headers, and the above uses `"` for top level, and `=` for each extension. Since gendoc just pastes it in verbatim, with `=` underlines, we get "Obsolescence Markers Discovery", "Effect Flag Experiment", and "Template keywords" as siblings to the evolve extension, instead of nested inside of it. This is not required for the string below it (that shows up with `hg help evolution`), as that is one level higher in the hierarchy (not nested inside of an "Extensions" section), so `=` is appropriate there.
-
Kyle Lippincott authored
This shouldn't be necessary, and by stripping it (and removing the trailing newline) it causes issues with Mercurial's doc/gendoc.py's RST output, since there's no newline separating this string and the thing that comes after it. I believe that the `.strip()` has been in there since the beginning, but I have not found a reason for its existence. It's possible that this was required in older Mercurial versions, but is no longer required? Notably, the tests (which include an invocation of `hg help evolution`) still pass with this change. ### Alternatives considered - Making gendoc.py robust against this. This was rejected since there's no need for the .strip() as far as I can tell, and this is the only case I know of that would need such logic.
-
- Nov 25, 2020
-
-
Martin von Zweigbergk authored
This patch removes the update of the working copy after each in-memory merge and only instead updates the working copy afterwards (if requested). There's still no significant speedup in the hg repo. It seems that the cost of updating the working copy is not large enough to make much difference, and the cost of reading and updating obsmarkers is relatively high in that repo. A significant part of the time (~35%) is spent in `repoview.computehidden()` because it is recalculated for every commit (seems like potential for improvement). I made similar changes in the mozilla-unified repo (which has a significantly larger working copy), by adding 10 commits each changing one line of a file. There, evolving 9 of those commits took 34s before this patch and 20s after. I measured similar speedups in an internal repo (9.0s -> 5.2s).
-
- Oct 15, 2020
-
-
Martin von Zweigbergk authored
This patch adds a config option to let run evolve's relocation step using in-memory merge. It is disabled by default. When the option is on, the relocation is first attempted in memory. If that fails because of merge conflicts, it retries that commit in the working copy. There are a few reasons that I made it configurable. The most important one is that the precommit hook won't trigger when using in-memory merge. Another reason is that it lets us roll out the feature slowly to our users at Google. For now, we also update the working copy after creating the commit (in the successful case, when there are no merge conflicts). The next patch will make it so we don't do that update. Because of the unnecessary working-copy update, this patch doesn't provide any benefit on its own. Evolving 29 commits that each change one line in the hg slows down from ~4.5s to ~4.8s when the config option is on. I've added `#testcases inmemory ondisk` to select `.t` files. Almost all differences are because of the new "hit merge conflicts" message and retrying the merge. There's also one difference in `test-stabilize-order.t` caused by the different order of working copy updates (we now update the working copy at the end).
-
- Oct 01, 2020
-
-
Martin von Zweigbergk authored
The next patch will make `hg evolve` use in-memory merge. This patch adds a test case for that. I'm adding it before the implementation so it's easy to see what the behavior change is.
-
- Oct 15, 2020
-
-
Martin von Zweigbergk authored
The logic for rewriting hashes is somewhat long and well isolated, so a function makes good sense.
-
- Feb 09, 2021
-
-
Anton Shestakov authored
-