Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 May 2017 11:37:18 -0700] rev 32312
rebase: allow rebase even if some revisions need no rebase (BC) (issue5422)
This allows you to do e.g. "hg rebase -d @ -r 'draft()'" even if some
drafts are already based off of @. You'd still need to exclude
obsolete and troubled revisions, though. We will deal with those cases
later.
Implemented by treating state[rev]==rev as "no need to rebase". I
considered adding another fake revision number like revdone=-6. That
would make the code clearer in a few places, but would add extra code
in other places.
I moved the existing test out of test-rebase-base.t and into a new
file and added more tests there, since not all are using --base.
Jun Wu <quark@fb.com> [Wed, 10 May 2017 11:55:22 -0700] rev 32311
chgserver: more explicit about sensitive environ variables
Environment variables like HGUSER, HGEDITOR, HGEDITFROM should not trigger
a new chgserver. This patch uses a whitelist for environ variables starting
with "HG" to reduce the number of servers.
I have went through `grep -o "[\"']HG[A-Z_0-9]*['\"]" -hR . | sort -u` so
the list should be up-to-date.
Kostia Balytskyi <ikostia@fb.com> [Thu, 11 May 2017 08:49:33 -0700] rev 32310
scmutil: make simplekeyvaluefile able to have a non-key-value first line
To ease migration from files with version numbers in their first lines,
we want simplekeyvaluefile to support a non-key-value first line. In this
way, old versions of Mercurial will read such files, discover a newer version
than the one they know how to handle and fail gracefully, rather than with
exception. Shelve's shelvestate file is an example.
Kostia Balytskyi <ikostia@fb.com> [Thu, 11 May 2017 08:39:44 -0700] rev 32309
scmutil: add simplekeyvaluefile reading test
Before this patch, mockvfs did not emulate readlines correctly
and there was no test for simplekeyvaluefile reading.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 18:57:52 +0200] rev 32308
caches: stop warming the cache after changegroup application
Now that we garantee that branchmap cache is updated at the end of the
transaction we can drop this update. This removes a problematic case with
nested transaction where the new cache could be written on disk before the
transaction is finished (and even roll-backed)
Such premature cache write was visible in the following test:
* tests/test-acl.t
* tests/test-rebase-conflicts.t
In addition, running the cache update later means having more date about the
state of the repository (in particular: phases). So we can generate caches with
more information. This creates harmless changes to the following tests:
* tests/test-hardlinks-whitelisted.t
* tests/test-hardlinks.t
* tests/test-phases.t
* tests/test-tags.t
* tests/test-inherit-mode.t
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 22:27:44 +0200] rev 32307
caches: move the 'updating the branch cache' message in 'updatecaches'
We are about to remove the branchmap cache update in changegroup application.
There is a debug message alongside this update that we do not want to loose. We
move the message beforehand to simplify the test update in the next changeset.
The message move is quite noisy and isolating that noise is useful.
Most tests update are just line reordering since the message is issued at a
later point during the transaction.
After this changes, the message is displayed in more case since local commit
creation also issue it.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 18:56:07 +0200] rev 32306
caches: stop warming the cache after 'localrepo.commitctx'
Now that we garantee that branchmap cache are updated at the end of the
transaction we can drop that one. This removes a problematic case with nested
transaction where the new cache could be written on disk before the transaction
is finished.
The test change is harmless, since we update the cache at a later point, the
dirstate have been updated in between.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 21:35:06 +0200] rev 32305
caches: introduce a 'debugupdatecaches' command
That command make sure caches are updated. This is based on
'localrepo.updatecaches' so when we move support for new cache in that function this
command will benefit from it.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 19:05:58 +0200] rev 32304
caches: call 'repo.updatecache()' in 'repo.destroyed()'
Regenerating the cache after a 'strip' or a 'rollback' is useful. So we call the
generic cache warming function as other caches than just branchmap will be
updated there in the future.
To do so, we have to make 'repo.updatecache()' able to take no arguments. In
such cases, we reload all caches.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 21:39:43 +0200] rev 32303
caches: introduce a function to warm cache
We have multiple caches that gain from being kept up to date. For example in a
server setup, we want to make sure the branchcache cache is hot for other
read-only clients.
Right now each cache tries to update themself in place where new data have been
added. However the approach is error prone (we might miss some spot) and
fragile. When nested transaction are involved, such cache updates might happen
before a top level transaction is committed. Writing caches for uncommitted
data on disk.
Having a single entry point, run at the end of each successful transaction,
helps to ensure the cache is up to date and refreshed at the right time.
We start with updating the branchmap cache but other will come.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 18:45:51 +0200] rev 32302
transaction: track newly introduced revisions
Tracking revisions is not the data that will unlock the most new capability.
However, they are the simplest thing to track and still unlock some nice
improvements in regard with caching.
We plug ourself at the changelog level to make sure we do not miss any revision
additions.
The 'revs' set is configured at the repository level because the transaction
itself does not needs to know that much about the business logic.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 18:31:18 +0200] rev 32301
transaction: introduce "changes" dictionary to precisely track updates
The transaction is already tracking some data intended for hooks (in
'hookargs'). However, that information is minimal as we optimise for
passing data to other processes through environment variables. There are
multiple places were we could use more complete and lower level
information locally (eg: cache update, better report of changes to
hooks, etc...).
For this purpose we introduces a 'changes' dictionary on the
transaction. It is intended to track every changes happening to the
repository (eg: new revs, bookmarks move, phases move, obs-markers,
etc).
For now we just adds the 'changes' dictionary. We'll adds more tracking
and usages over time.