Wed, 15 Apr 2015 15:22:16 -0400 largefiles: for update -C, only update largefiles when necessary
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Apr 2015 15:22:16 -0400] rev 24787
largefiles: for update -C, only update largefiles when necessary Before, a --clean update with largefiles would use the "optimization" that it didn't read hashes from standin files before and after the update. Instead of trusting the content of the standin files, it would rehash all the actual largefiles that lfdirstate reported clean and update the standins that didn't have the expected content. It could thus in some "impossible" situations automatically recover from some "largefile got out sync with its standin" issues (even there apparently still were weird corner cases where it could fail). This extra checking is similar to what core --clean intentionally do not do, and it made update --clean unbearable slow. Usually in core Mercurial, --clean will rely on the dirstate to find the files it should update. (It is thus intentionally possible (when trying to trick the system or if there should be bugs) to end up in situations where --clean not will restore the working directory content correctly.) Checking every file when we "know" it is ok is however not an option - that would be too slow. Instead, trust the content of the standin files. Use the same logic for --clean as for linear updates and trust the dirstate and that our "logic" will keep them in sync. It is much cheaper to just rehash the largefiles reported dirty by a status walk and read all standins than to hash largefiles. Most of the changes are just a change of indentation now when the different kinds of updates no longer are handled that differently. Standins for added files are however only written when doing a normal update, while deleted and removed files only will be updated for --clean updates.
Wed, 15 Apr 2015 11:49:44 -0400 subrepo: calculate _relpath for hgsubrepo based on self instead of parent
Matt Harbison <matt_harbison@yahoo.com> [Wed, 15 Apr 2015 11:49:44 -0400] rev 24786
subrepo: calculate _relpath for hgsubrepo based on self instead of parent Prior to 105758d1b37b, the subrelpath() (now _relpath) for hgsubrepo was calculated by removing the root path of the outermost repo from the root path of the subrepo. Since the root paths use platform specific separators, and the relative path is printed by various commands, the output of these commands require a glob (and check-code.py enforces this). In an effort to be generic to all subrepos, 105758d1b37b started calculating this path based on the parent repo, and then joining the subrepo path in .hgsub. One of the tests in test-subrepo.t creates a subrepo inside a directory, so the path being joined contained '/' instead of '\'. This made the test fail with a '~' status, because the glob is unnecessary[1]. Removing them made the test work, but then check-code complains. We can't just drop the check-code rule, because sub-subrepos are still joined with '\'. Presumably the other subrepo types have this issue as well, but there likely isn't a test with git or svn repos inside a subdirectory. This simply restores the exact _relpath value (and output) for hgsubrepos prior to 105758d1b37b. [1] http://www.selenic.com/pipermail/mercurial-devel/2015-April/068720.html
Wed, 15 Apr 2015 11:23:26 -0400 subrepo: backout 93b0e0db7929 to restore reporelpath()
Matt Harbison <matt_harbison@yahoo.com> [Wed, 15 Apr 2015 11:23:26 -0400] rev 24785
subrepo: backout 93b0e0db7929 to restore reporelpath() The path for hgsubrepo needs to be calculated slightly differently from other subrepo types, but can reuse this. See the next patch for details.
Thu, 16 Apr 2015 18:48:20 -0500 rollback: clear resolve state (issue4593)
Matt Mackall <mpm@selenic.com> [Thu, 16 Apr 2015 18:48:20 -0500] rev 24784
rollback: clear resolve state (issue4593)
Thu, 16 Apr 2015 11:31:48 -0700 diff: pass the diff matcher to the copy logic
Durham Goode <durham@fb.com> [Thu, 16 Apr 2015 11:31:48 -0700] rev 24783
diff: pass the diff matcher to the copy logic This passes the existing diff matcher instance down to the copy logic so copy tracing can be more efficient when possible and only trace copies for matching files. This only actually affects forwardcopies (i.e. Given A<-B<-C<-D, it works for 'hg diff -r B -r D foo.txt', but not for 'hg diff -r D -r B foo.txt') since backward copies require walking all histories, and not just the individual file's. This reduces 'hg diff -r A -r B foo.txt' time from 15s to 1s when A and B have 80,000 files different.
Thu, 16 Apr 2015 11:29:30 -0700 copies: add matcher parameter to copy logic
Durham Goode <durham@fb.com> [Thu, 16 Apr 2015 11:29:30 -0700] rev 24782
copies: add matcher parameter to copy logic This allows passing a matcher down the pathcopies() stack to _forwardcopies(). This will let us add logic in a later patch to avoid tracing copies when not necessary (like when doing hg diff -r 1 -r 2 foo.txt).
Sun, 12 Apr 2015 23:01:18 -0700 treemanifest: extract parse method from constructor
Martin von Zweigbergk <martinvonz@google.com> [Sun, 12 Apr 2015 23:01:18 -0700] rev 24781
treemanifest: extract parse method from constructor When we start to lazily load submanifests, it will be useful to be able to create an treemanifest instance before manifest data gets parsed into it. To prepare for this, extract the parsing code from treemanifest's constructor to a separate method.
Sun, 12 Apr 2015 14:37:55 -0700 manifest: duplicate call to addrevision()
Martin von Zweigbergk <martinvonz@google.com> [Sun, 12 Apr 2015 14:37:55 -0700] rev 24780
manifest: duplicate call to addrevision() When we start writing submanifests to their own revlogs, we will not want to write a new revision for a directory if there were no changes to it. To prepare for this, duplicate the call to addrevision() and move them earlier where they can more easily be avoided.
Thu, 16 Apr 2015 14:26:50 -0700 record: add message when starting record's curses interface
Laurent Charignon <lcharignon@fb.com> [Thu, 16 Apr 2015 14:26:50 -0700] rev 24779
record: add message when starting record's curses interface We are adding this log message to reduce a confusion when a command prints something just before starting the curses interface. Since the interactive mode is taking over the entire screen, starts with no delay and does wait for a key press, the user believes that messages printed before opening the interactive mode were actually printed after using interactive mode, not before. The fix adds the line "Starting interactive mode" helping the user separate the messages that were printed before and after the start of the interactive mode. One particular example where this was a problem is the revert command where we first print the list of changes to be considered for revert, then opens the curses interface right away without letting the user see the messages. The user then selects the changes, validates and then see the messages from before opening the interactive mode and is confused.
Tue, 14 Apr 2015 20:09:56 +0200 subrepo: add include/exclude support for diffing git subrepos
Mathias De Maré <mathias.demare@gmail.com> [Tue, 14 Apr 2015 20:09:56 +0200] rev 24778
subrepo: add include/exclude support for diffing git subrepos Previously, git subrepos were ignored if any type of path selection was done. This can be solved by using subrepo status and filtering matching files.
Sun, 12 Apr 2015 19:00:31 +0900 revset: undocument wdir() until its command outputs get stable
Yuya Nishihara <yuya@tcha.org> [Sun, 12 Apr 2015 19:00:31 +0900] rev 24777
revset: undocument wdir() until its command outputs get stable wdir() implementation is still incomplete and shouldn't be advertised to users. This patch will be backed out when - template values such as {rev} and {node} are settled - major commands and revsets work without crashing
Thu, 16 Apr 2015 18:30:08 -0500 linkrev: fix issue with annotate of working copy
Matt Mackall <mpm@selenic.com> [Thu, 16 Apr 2015 18:30:08 -0500] rev 24776
linkrev: fix issue with annotate of working copy The introrev was appearing as None in new annotate tests, which the code from the stable branch wasn't expecting.
Thu, 16 Apr 2015 17:30:01 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 16 Apr 2015 17:30:01 -0500] rev 24775
merge with stable
Sat, 04 Apr 2015 02:16:48 -0700 histedit: delete all non-actionclass related code
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 02:16:48 -0700] rev 24774
histedit: delete all non-actionclass related code Now that all actions have been migrated to the class format, we can delete all the unnecessary code that supported the old function format.
Sat, 04 Apr 2015 02:12:53 -0700 histedit: improve roll action integration with fold
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 02:12:53 -0700] rev 24773
histedit: improve roll action integration with fold Previously the fold action would inspect it's class to figure out if it was a rollup or not. This was hacky. Now that finishfold is inside the fold class, let's modify it to check a function (which roll can override) to determine if it should be prompting for a commit message.
Sat, 04 Apr 2015 02:12:24 -0700 histedit: move finishfold into fold class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 02:12:24 -0700] rev 24772
histedit: move finishfold into fold class Let's move the finishfold function into the fold class so we can modify it from the roll class more easily.
Sat, 04 Apr 2015 02:03:27 -0700 histedit: convert fold/roll actions into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 02:03:27 -0700] rev 24771
histedit: convert fold/roll actions into a class This converts the fold/roll actions into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness. The tests changed for two reasons: 1) We get a new 'empty changeset' warning because we now warn more consistently between normal histedit and --continue about commits disappearing. 2) Previously we were not putting the histedit-source extra field on the temporary fold commit during normal runs, but we were on --continue runs. By unifying these code paths we now consistently put histedit-source on the temporary fold commit, which changes some of the hashes in the backup bundles.
Sat, 04 Apr 2015 01:00:51 -0700 histedit: convert edit action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 01:00:51 -0700] rev 24770
histedit: convert edit action into a class This converts the edit action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness.
Sat, 04 Apr 2015 00:42:32 -0700 histedit: convert message action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 00:42:32 -0700] rev 24769
histedit: convert message action into a class This converts the message action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness.
Sat, 04 Apr 2015 00:30:01 -0700 histedit: convert drop action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 00:30:01 -0700] rev 24768
histedit: convert drop action into a class This converts the drop action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness.
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 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip