Idan Kamara <idankk86@gmail.com> [Wed, 09 Jan 2013 20:37:44 +0200] rev 18313
destroyed: keep the filecache in sync with __dict__ (issue3335) (issue3693) (issue3743)
We need to make sure that if X is in the filecache then it's also in the
filecache owner's __dict__, otherwise it will go out of sync:
repo.X # first access to X, records stat info in
# filecache and updates __dict__
repo._filecache.clear() # removes X from _filecache but it's still in __dict__
repo.invalidate() # iterates over _filecache and removes entries
# from __dict__, but X isn't in _filecache, so
# it's kept in __dict__
repo.X # X is fetched from __dict__, bypassing the filecache
Idan Kamara <idankk86@gmail.com> [Fri, 11 Jan 2013 00:05:52 +0200] rev 18312
localrepo: write the phasecache when destroying nodes
Idan Kamara <idankk86@gmail.com> [Sat, 05 Jan 2013 16:50:12 +0200] rev 18311
localrepo: update the branchmap when destroying nodes
This was previously called directly during strip. Moving it to destroying
also means that it'll be called through _rollback, which seems harmless.
Idan Kamara <idankk86@gmail.com> [Sat, 15 Dec 2012 20:08:13 +0200] rev 18310
localrepo: introduce destroying function
Idan Kamara <idankk86@gmail.com> [Sun, 16 Dec 2012 23:13:02 +0200] rev 18309
localrepo: don't refresh filecache entries that aren't in __dict__
We call invalidate to remove properties from __dict__ because they're
possibly outdated and we'd like to check for a new version. Next time
the property is accessed the filecache mechanism checks the current stat
info with the one recorded at the last time the property was read, if
they're different it recreates the property.
Previously we refreshed the stat info on all properties in the filecache
when the lock is released, including properties that are missing from
__dict__. This is a problem because:
l = repo.lock()
repo.P # stat info S for P is recorded in _filecache
<changes are made to repo.P indirectly, e.g. underlying file is replaced>
# P's new stat info = S'
l.release() # filecache refreshes, records S' as P's stat info
At this point our filecache contains P with stat info S', but P's
version is from S, which is outdated.
The above happens during _rollback and strip. Currently we're wiping the
filecache and forcing everything to reload from scratch which works but
isn't the right solution.
Mads Kiilerich <mads@kiilerich.com> [Sat, 12 Jan 2013 16:04:29 +0100] rev 18308
changelog: please check-code and remove tabs
Tabs were introduced in 06185554e7e3.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 11 Jan 2013 18:47:42 +0100] rev 18307
branchmap: Save changectx creation during update
The newly introduced `branchmap` function allows us to skip the
creation of changectx objects. This speeds up the construction of
the branchmap.
On the mozilla repository (117293 changesets, 15490 mutable)
Before:
! impactable 19.9
! mutable 0.576
! unserved 3.16
After:
! impactable 7.03 (2.8x faster)
! mutable 0.352 (1.6x)
! unserved 1.15 (2.7x)
On the cpython repository (81418 changesets, 6418 mutable)
Before:
! impactable 15.9
! mutable 0.451
! unserved 0.861
After:
! impactable 6.55 (2.4x faster)
! mutable 0.170 (2.6x faster)
! unserved 0.289 (2.9x faster)
On the pypy repository (58852 changesets)
Before:
! impactable 13.6
After:
! impactable 6.17 (2.2x faster)
On my Mercurial repository (18295 changesets, 2210 mutable)
Before:
! impactable 23.9
! mutable 0.368
! unserved 0.057
After:
! impactable 1.31 (18x faster)
! mutable 0.042 (8.7x)
! unserved 0.025 (2.2x)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 10 Jan 2013 00:41:40 +0100] rev 18306
changelog: add a `branch` method, bypassing changectx
The only way to access the branch of a changeset is currently to
create a changectx object and access its `branch()` method. Creating
a new Python object is costly and has a huge impact on code doing
heavy access to `branch()` (like branchmap).
This change introduces a new method on changelog that allows direct
access to the branch of a revision. See the next changeset for impact.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 08 Jan 2013 01:28:39 +0100] rev 18305
branchmap: pass revision insteads of changectx to the update function
Creation of changectx objects is very slow, and they are not very
useful. We are going to drop them. The first step is to change the
function argument type.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 11 Jan 2013 18:39:43 +0100] rev 18304
perf: add perfbranchmap command
The command times the update of a branchmap from its nearest subset
or from scratch.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 11 Jan 2013 20:34:54 +0100] rev 18303
clfilter: enforce hidden filtering on all repository accesses
We ensure all repositores created through `mercurial.hg.repository`
are "hidden" filtered. This is an even stronger enforcement than
5bb610f87d1d.
Citing Matt's response to changeset 5bb610f87d1d installing filtering
in dispatch:
> Unfortunately, this means that code that doesn't go through dispatch (ie all
> those crazy misguided people using Mercurial as a library) are going to see
> these hidden changesets.
>
> Might be better to instead install the filter in localrepo construction by
> default and disable it in dispatch.
Mads Kiilerich <madski@unity3d.com> [Thu, 03 Jan 2013 21:07:04 +0100] rev 18302
archival: avoid touching deprecated gzip name attribute
The existing workaround didn't work when no filename was specified.
If running in a context with warnings enabled and subsecond mtime it gave a
warning:
DeprecationWarning: use the name attribute
Mads Kiilerich <madski@unity3d.com> [Thu, 03 Jan 2013 21:07:04 +0100] rev 18301
archival: pass integer to struct.pack int field instead of float
If running in a context with warnings enabled and subsecond mtime it gave a
warning:
DeprecationWarning: integer argument expected, got float
Mads Kiilerich <madski@unity3d.com> [Fri, 11 Jan 2013 16:30:29 +0100] rev 18300
largefiles: fix update from a merge with removed files
A situation with this case could happen after interrupting an update. Update
would fail with:
abort: No such file or directory: $TESTTMP/f/.hglf/sub2/large6
Update from a merge without using clean is not possible anyway, so this patch
takes a step in the right direction so it gets as far as reporting the right
error.
Mads Kiilerich <madski@unity3d.com> [Fri, 11 Jan 2013 16:30:29 +0100] rev 18299
largefiles: fix revert removing a largefile from a merge
Before revert could fail with:
abort: .hglf/large@33fdd332ec64: not found in manifest!
The LookupError will now be caught and handled correctly.
Mads Kiilerich <madski@unity3d.com> [Fri, 11 Jan 2013 16:30:29 +0100] rev 18298
largefiles: remove unused proto.refuseclient code
Should have been removed with other pre-1.9 code in 7c604d8c7e83.