Adrian Buehlmann <adrian@cadifra.com> [Fri, 14 Sep 2012 13:02:31 +0200] rev 17553
perf: add perffncacheencode
Examples (all done with somewhat dated clones I found on my disk):
Netbeans (~120k entries in fncache):
$ hg perffncacheencode
! wall 4.338000 comb 4.336828 user 4.336828 sys 0.000000 (best of 3)
Openoffice (~77k entries in fncache)):
$ hg perffncacheencode
! wall 1.533000 comb 1.528810 user 1.528810 sys 0.000000 (best of 7)
Xen (~10k entries in fncache):
$ hg perffncacheencode
! wall 0.198000 comb 0.187201 user 0.187201 sys 0.000000 (best of 51)
Done on Windows 7 x64.
Bryan O'Sullivan <bryano@fb.com> [Thu, 13 Sep 2012 17:00:56 -0700] rev 17552
Merge with mpm
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sun, 26 Aug 2012 01:28:22 +0200] rev 17551
bookmark: take successors into account when updating (issue3561)
When we rewrite a bookmarked changeset, we want to update the
bookmark on its successors. But the successors are not descendants
of its precursor (by definition). This changeset alters the bookmarks
logic to update bookmark location if the newer location is a successor
of the old one[1].
note: valid destinations are in fact any kind of successors of any kind
of descendants (recursively.)
This changeset requires the enabling of the obsolete feature in
some bookmark tests.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sun, 26 Aug 2012 00:28:56 +0200] rev 17550
bookmarks: extract valid destination logic in a dedicated function
We usually update bookmarks only if the new location is descendant of the old
bookmarks location. We extract this logic into a function. This is the first
step to allow more complex logic using obsolescence in this validation of the
bookmark movement.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sun, 26 Aug 2012 00:27:44 +0200] rev 17549
checkheads: don't warn about unsynced changes that we ill obsolete
We won't be able to pull them after this push.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sun, 26 Aug 2012 00:25:33 +0200] rev 17548
checkheads: check successors for new heads in both missing and common
A relevant obsolete marker may have been added -after- we previously
exchanged the changeset. We have to search for remote heads that
disappear by the sole fact of pushing obsolescence.
This case will also happen when remote got the new version from a
repository that does not propagate obsolescence markers.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 24 Aug 2012 16:52:45 +0200] rev 17547
checkheads: attend to phases when computing new heads with obsolete
Checkheads was more permissive than expected. When the remote heads
are public we don't need to search for successors. None will make a
public head disappear.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 01 Aug 2012 19:35:05 +0200] rev 17546
test: add testing of checkheads behavior with obsolete
Expected behavior is quite complex. Explicit testing with clear
scenarios is welcome.
Matt Mackall <mpm@selenic.com> [Thu, 13 Sep 2012 14:33:10 -0500] rev 17545
merge with stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 11 Sep 2012 10:59:21 -0300] rev 17544
i18n-pt_BR: synchronized with f5e86b416e05
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 11 Sep 2012 10:56:23 -0300] rev 17543
merge with i18n
Martin Schröder <martin.schroeder@nerdluecht.de> [Mon, 10 Sep 2012 09:40:42 +0200] rev 17542
i18n-de: Remove unused sprintf parameter