Wed, 09 Jan 2013 00:01:33 +0100 scmutil: simplify vfs.audit - drop wrapped vfs.auditor
Mads Kiilerich <mads@kiilerich.com> [Wed, 09 Jan 2013 00:01:33 +0100] rev 18327
scmutil: simplify vfs.audit - drop wrapped vfs.auditor
Thu, 10 Jan 2013 00:44:23 +0100 util: copyfile: remove dest before copying
Mads Kiilerich <mads@kiilerich.com> [Thu, 10 Jan 2013 00:44:23 +0100] rev 18326
util: copyfile: remove dest before copying This prevents spurious problems writing to locked files on Windows.
Tue, 15 Jan 2013 01:05:11 +0100 merge: warn when internal:merge cannot merge symlinks
Mads Kiilerich <mads@kiilerich.com> [Tue, 15 Jan 2013 01:05:11 +0100] rev 18325
merge: warn when internal:merge cannot merge symlinks A follow-up to d084df89d948. internal:merge should never be picked for merging symlinks ... but in the test suite we have HGMERGE="internal:merge" which bypasses all the usual merge-tool cleverness. Without any output it can be hard to figure out what happened and where the problem is.
Mon, 14 Jan 2013 10:17:06 -0600 merge with stable
Kevin Bullock <kbullock@ringworld.org> [Mon, 14 Jan 2013 10:17:06 -0600] rev 18324
merge with stable
Mon, 14 Jan 2013 23:14:45 +0900 histedit: correct the number of added revisions in online help stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 14 Jan 2013 23:14:45 +0900] rev 18323
histedit: correct the number of added revisions in online help In the context of help document on which this patch focuses, the example repository, which is source of cloning, should be already histedit-ed, and contain only 3 revisions (rev # 0 to 2). So, not 3, but 4 revisions should be added to the destination repository of cloning, if it contains 7 revisions (rev # 0 to 6). This patch also adds modifier "histedit-ed" to "example repository", to make context clear.
Mon, 14 Jan 2013 23:14:45 +0900 histedit: correct changeset IDs in online help stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 14 Jan 2013 23:14:45 +0900] rev 18322
histedit: correct changeset IDs in online help There is no '633536316234' revision in the example repository. It should be 'c561b4e977df', according to the revisions in it and explanation in help document.
Mon, 14 Jan 2013 23:14:45 +0900 convert: correct 'hooks' section name in online help stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 14 Jan 2013 23:14:45 +0900] rev 18321
convert: correct 'hooks' section name in online help The section name for hooks is not 'hook', but 'hooks'.
Sun, 13 Jan 2013 21:36:35 +0100 hgweb: document the revnavgen function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sun, 13 Jan 2013 21:36:35 +0100] rev 18320
hgweb: document the revnavgen function
Wed, 19 Dec 2012 19:06:50 +0100 hgweb: no do not use listinsert(0, ...)
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 19 Dec 2012 19:06:50 +0100] rev 18319
hgweb: no do not use listinsert(0, ...) This is not efficient. We now append element and either reverse the list or iterate in reverse order.
Thu, 10 Jan 2013 23:57:03 +0200 localrepo: drop unnecessary check on wlock unlock
Idan Kamara <idankk86@gmail.com> [Thu, 10 Jan 2013 23:57:03 +0200] rev 18318
localrepo: drop unnecessary check on wlock unlock Calling out to dirstate one line before guarantees that it'll be in the filecache.
Sun, 16 Dec 2012 20:33:00 +0200 dirstate: refresh _branch cache entry after writing it
Idan Kamara <idankk86@gmail.com> [Sun, 16 Dec 2012 20:33:00 +0200] rev 18317
dirstate: refresh _branch cache entry after writing it
Mon, 17 Dec 2012 15:25:45 +0200 filecache: create an entry in _filecache when __set__ is called for a missing one
Idan Kamara <idankk86@gmail.com> [Mon, 17 Dec 2012 15:25:45 +0200] rev 18316
filecache: create an entry in _filecache when __set__ is called for a missing one Preserve the invariant that if P is a filecached property on X then P in X.__dict__ => P in X._filecache. Previously, it was possible for a filecached property to become out of sync with the filesystem if it was set before getting it first, since the initial filecacheentry was created in __get__. Old behaviour: repo.prop = x repo.invalidate() # prop has no entry in _filecache, it's not removed # from __dict__ repo.prop # returns x like before without checking with the # filesystem New: repo.prop = x # an empty entry is created in _filecache repo.invalidate() # prop is removed from __dict__ repo.prop # recreates prop
Thu, 10 Jan 2013 23:54:53 +0200 filecache: allow filecacheentry to be created without stating in __init__
Idan Kamara <idankk86@gmail.com> [Thu, 10 Jan 2013 23:54:53 +0200] rev 18315
filecache: allow filecacheentry to be created without stating in __init__ Will be used for properties that are set without getting them first.
Wed, 09 Jan 2013 20:36:53 +0200 rollback: don't clear the filecache
Idan Kamara <idankk86@gmail.com> [Wed, 09 Jan 2013 20:36:53 +0200] rev 18314
rollback: don't clear the filecache This was an old workaround to force the filecache to reload everything. Now that the syncing issue is fixed, we no longer need it.
Wed, 09 Jan 2013 20:37:44 +0200 destroyed: keep the filecache in sync with __dict__ (issue3335) (issue3693) (issue3743)
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
Fri, 11 Jan 2013 00:05:52 +0200 localrepo: write the phasecache when destroying nodes
Idan Kamara <idankk86@gmail.com> [Fri, 11 Jan 2013 00:05:52 +0200] rev 18312
localrepo: write the phasecache when destroying nodes
Sat, 05 Jan 2013 16:50:12 +0200 localrepo: update the branchmap 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.
Sat, 15 Dec 2012 20:08:13 +0200 localrepo: introduce destroying function
Idan Kamara <idankk86@gmail.com> [Sat, 15 Dec 2012 20:08:13 +0200] rev 18310
localrepo: introduce destroying function
Sun, 16 Dec 2012 23:13:02 +0200 localrepo: don't refresh filecache entries that aren't in __dict__
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.
Sat, 12 Jan 2013 16:04:29 +0100 changelog: please check-code and remove tabs
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.
Fri, 11 Jan 2013 18:47:42 +0100 branchmap: Save changectx creation during update
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)
Thu, 10 Jan 2013 00:41:40 +0100 changelog: add a `branch` method, bypassing changectx
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.
Tue, 08 Jan 2013 01:28:39 +0100 branchmap: pass revision insteads of changectx to the update function
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.
Fri, 11 Jan 2013 18:39:43 +0100 perf: add perfbranchmap command
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.
Fri, 11 Jan 2013 20:34:54 +0100 clfilter: enforce hidden filtering on all repository accesses
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.
Thu, 03 Jan 2013 21:07:04 +0100 archival: avoid touching deprecated gzip name attribute
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
Thu, 03 Jan 2013 21:07:04 +0100 archival: pass integer to struct.pack int field instead of float
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
Fri, 11 Jan 2013 16:30:29 +0100 largefiles: fix update from a merge with removed files
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.
Fri, 11 Jan 2013 16:30:29 +0100 largefiles: fix revert removing a largefile from a merge
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.
Fri, 11 Jan 2013 16:30:29 +0100 largefiles: remove unused proto.refuseclient code
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.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 +30000 tip