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.

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.

rebase: restore bookmark state on abort The bookmark state was already being preserved, but it wasn't being properly restored.

histedit: store backup file before histedit It's possible for the user to delete some of the commits they started with during a histedit, and aborting the histedit doesn't bring them back. Let's store a backup bundle so we can always recover the stack of commits from before they began.

histedit: replace pickle with custom serialization Pickle is undesirable, so let's serialize it ourselves. We keep the ability to parse existing pickle blobs for now.

devel-warn: add a prefix to all messages ("devel-warn: ") We want to make the origin and importance of the message clear to developers.

push: acquire local 'wlock' if "pushback" is expected (BC) (issue4596) If the client allows "pushback", the bundle2 served back by the server may contains parts that will write to the repository. Such parts may require the 'wlock' (eg: bookmark) so we acquire it in advance to make sure it got acquired before the 'lock'.