Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Nov 2014 14:51:18 -0800] rev 23258
add: add back forgotten files even when not matching exactly (BC)
I accidentally did 'hg forget .' and tried to undo the operation with
'hg add .'. I expected the files to be reported as either modified or
clean, but they were still reported as removed. It turns out that
forgotten files are only added back if they are listed explicitly, as
shown by the following two invocations. This makes it hard to recover
from the mistake of forgetting a lot of files.
$ hg forget README && hg add README && hg status -A README
C README
$ hg forget README && hg add . && hg status -A README
R README
The problem lies in cmdutil.add(). That method checks that the file
isn't already tracked before adding it, but it does so by checking the
dirstate, which does have an entry for forgotten files (state 'r'). We
should instead be checking whether the file exists in the
workingctx. The workingctx is also what we later call add() on, and
that method takes care of transforming the add() into a normallookup()
on the dirstate.
Since we're changing repo.dirstate into wctx, let's also change
repo.walk into wctx.walk for consistency (repo.walk calls wctx.walk,
so we're simply inlining the call).
Martin von Zweigbergk <martinvonz@google.com> [Tue, 11 Nov 2014 10:16:54 -0800] rev 23257
context.status: explain "caching reasons" more fully
Where we "load earliest manifest first for caching reasons", elaborate
on what "caching reasons" refers to. Text provided by Matt in
http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/73235/focus=73578.
Augie Fackler <raf@durin42.com> [Tue, 11 Nov 2014 10:35:06 -0500] rev 23256
localrepo: rename revlog.maxchainlen to format.maxchainlen
This is more consistent with other option names, as spotted by Pierre-Yves. Thanks!
Mateusz Kwapich <mitrandir@fb.com> [Thu, 06 Nov 2014 14:20:05 -0800] rev 23255
revlog: add config variable for limiting delta-chain length
The current heuristic for deciding between storing delta and full texts
is based on ratio of (sizeofdeltas)/(sizeoffulltext).
In some cases (for example a manifest for ahuge repo) this approach
can result in extremely long delta chains (~30,000) which are very slow to
read. (In the case of a manifest ~500ms are added to every hg command because of that).
This commit introduces "revlog.maxchainlength" configuration variable that will
limit delta chain length.
Mateusz Kwapich <mitrandir@fb.com> [Thu, 06 Nov 2014 14:08:25 -0800] rev 23254
debugrevlog: fix computing chain length in debugrevlog -d
The chain length was computed correctly only when generaldelta
feature was enabled. Now it's fixed.
When generaldelta is disabled the base revision in revlog index is not
the revision we have delta against - it's always previous revision.
Instead of incorrect chainbaseandlen in command.py we are now using two
single-responsibility functions in revlog.py:
- chainbase(rev)
- chainlen(rev)
Only chainlen(rev) was missing so it was written to mimic the way the
chain of deltas is actually found during file reconstruction.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 10:13:01 +0000] rev 23253
transaction: factorise append-only file registration
The addition is done in two different places but differs slightly. We factorise
this addition to ensure it is consistent in all places.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 13:00:48 +0000] rev 23252
transaction: document `tr.add`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 10:05:38 +0000] rev 23251
transaction: drop backupentries logic from startgroup and endgroup
The `startgroup` and `endgroup` methods are used in a very specific
context to wrap a very specific operation (revlog truncation). It does
not make sense to perform any other operations during such a "group"
(eg:file backup). There is currently no user of backupfile during a
"group" so we drop the group-specific code and restrict authorized
operations during "group".
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 10:00:15 +0000] rev 23250
transaction: document startgroup and endgroup
These enigmatic methods are only used in repair. We document them to clarify
there purpose and user.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 09:31:57 +0000] rev 23249
transaction: mark backup-related attributes private
As the transaction is gaining more functions and attributes, it is important to clarify
what is part of the public API.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 01:30:29 +0000] rev 23248
transaction: document the contents of `tr.backupentries`
Now that all items are known we can document it.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 01:33:16 +0000] rev 23247
transaction: drop the third item in `tr.backupentries`
This third item is always None and never used.