Thu, 13 Sep 2012 17:00:56 -0700 Merge with mpm
Bryan O'Sullivan <bryano@fb.com> [Thu, 13 Sep 2012 17:00:56 -0700] rev 17552
Merge with mpm
Sun, 26 Aug 2012 01:28:22 +0200 bookmark: take successors into account when updating (issue3561)
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.
Sun, 26 Aug 2012 00:28:56 +0200 bookmarks: extract valid destination logic in a dedicated function
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.
Sun, 26 Aug 2012 00:27:44 +0200 checkheads: don't warn about unsynced changes that we ill obsolete
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.
Sun, 26 Aug 2012 00:25:33 +0200 checkheads: check successors for new heads in both missing and common
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.
Fri, 24 Aug 2012 16:52:45 +0200 checkheads: attend to phases when computing new heads with obsolete
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.
Wed, 01 Aug 2012 19:35:05 +0200 test: add testing of checkheads behavior with obsolete
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.
Thu, 13 Sep 2012 14:33:10 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 13 Sep 2012 14:33:10 -0500] rev 17545
merge with stable
Tue, 11 Sep 2012 10:59:21 -0300 i18n-pt_BR: synchronized with f5e86b416e05 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 11 Sep 2012 10:59:21 -0300] rev 17544
i18n-pt_BR: synchronized with f5e86b416e05
Tue, 11 Sep 2012 10:56:23 -0300 merge with i18n stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 11 Sep 2012 10:56:23 -0300] rev 17543
merge with i18n
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip