Sat, 04 Apr 2015 11:39:08 -0700 histedit: convert pick action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 11:39:08 -0700] rev 24767
histedit: convert pick action into a class This converts the pick action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness. The test output changed because previously pick would only report the commit disappearing if there were no merge conflicts. Now that we've unified the normal and the --continue flows, they act the same and we get the warning even after --continue.
Sat, 04 Apr 2015 11:37:08 -0700 histedit: integrate action class into flow
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 11:37:08 -0700] rev 24766
histedit: integrate action class into flow This takes the newly added histeditaction class and integrates it into the histedit run and bootstrapcontinue logic. No actions implement the class yet, but they will be add in upcoming patches.
Sat, 04 Apr 2015 11:34:53 -0700 histedit: add a new histeditaction class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 11:34:53 -0700] rev 24765
histedit: add a new histeditaction class This adds a new class called histeditaction. It represents a single action in a histedit plan. Future patches will integrate it into the histedit flow, then convert each existing action in to the class form one by one. This is part of a larger refactor aimed at increasing histedit robustness, maintainability, and extensibility.
Sat, 04 Apr 2015 01:00:05 -0700 histedit: allow histedit --continue when not on a descendant (BC)
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 01:00:05 -0700] rev 24764
histedit: allow histedit --continue when not on a descendant (BC) Previously we would not allow --continue if the current working copy parent was not a descendant of the commit produced by the previous histedit step. There's nothing really blocking us from continuing the histedit in this situation, so let's stop aborting in this case. This is technically a BC change, but it is making things more forgiving so I think it's ok. In the future we will likely add an 'exec' action to histedit, which means the user can do whatever they want during the middle of a histedit (like perhaps calling 'hg update'), which means we'll need to support this case eventually anyway.
Thu, 16 Apr 2015 11:59:36 -0400 tags: explicitly log which tags cache file is being written
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Apr 2015 11:59:36 -0400] rev 24763
tags: explicitly log which tags cache file is being written We now have multiple tags cache files. Record exactly which file is being written. This should help aid debugging into performance issues with any single filter.
Thu, 16 Apr 2015 11:54:13 -0400 tags: write a separate tags cache file for unfiltered repos
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Apr 2015 11:54:13 -0400] rev 24762
tags: write a separate tags cache file for unfiltered repos Since we changed the format of the tags cache, we should bump the filename. Before this patch, "tags" was being used for unfiltered repositories. Change the naming scheme to be consistent and ensure that a new cache file is used. While I was here, I updated the docs to describe the existence of multiple caches. I also added explicit test coverage for the creation of the unfiltered tags cache.
Thu, 16 Apr 2015 11:32:46 -0400 tags: return empty list of heads for no .hgtags case
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Apr 2015 11:32:46 -0400] rev 24761
tags: return empty list of heads for no .hgtags case The caller only uses the heads to resolve tags from content of .hgtags. Returning a non-empty array is pointless if there is no .hgtags file.
Thu, 16 Apr 2015 12:01:00 -0400 tags: change format of tags cache files
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Apr 2015 12:01:00 -0400] rev 24760
tags: change format of tags cache files .hgtags fnodes are now written to a shared cache file. They don't need to exist in the per-filter tags cache files. Stop writing them. The format of the tags cache file has changed in a backwards incompatible way. This should be acceptable, as we just established per-filter tags cache files and no client should have per-filter tags cache files that will need to be read. So no backwards compatbility concern is present. The new format has a single header line followed by resolved tags entries. The header line is similar to the old first line with a major difference: we now compute and store a hash of the filtered revisions. Before, if the set of filtered revs changed, we may return incorrect results. We now detect that. A test for verifying filtered rev change is handled properly has been added.
Thu, 16 Apr 2015 10:12:44 -0400 tags: don't read .hgtags fnodes from tags cache files
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Apr 2015 10:12:44 -0400] rev 24759
tags: don't read .hgtags fnodes from tags cache files Now that we have a standalone and shared cache for .hgtags fnodes, the .hgtags fnodes stored in the tags cache files are redundant. Upcoming patches will change the format of the tags cache files to remove this data and to improve the validation. To prepare for this, we change the tags reading code to ignore all but the tip .hgtags fnodes entries in existing tags cache files. All fnodes lookups now go through our new shared cache, which is why test output changed. Format of tags cache files has not yet changed.
Mon, 13 Apr 2015 14:54:02 -0400 rebase: restore bookmark state on abort
Tony Tung <tonytung@fb.com> [Mon, 13 Apr 2015 14:54:02 -0400] rev 24758
rebase: restore bookmark state on abort The bookmark state was already being preserved, but it wasn't being properly restored.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip