Sat, 06 Jun 2015 22:10:18 -0400 largefiles: ignore hidden changesets with 'verify --large --lfa'
Matt Harbison <matt_harbison@yahoo.com> [Sat, 06 Jun 2015 22:10:18 -0400] rev 25508
largefiles: ignore hidden changesets with 'verify --large --lfa' Previously, if there were any hidden changesets, the --lfa argument would cause the command to abort with a hint about using --hidden when it tripped over a hidden changeset.
Wed, 10 Jun 2015 14:49:27 -0700 bundle2: clarify in docstring that header size is for a single header
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Jun 2015 14:49:27 -0700] rev 25507
bundle2: clarify in docstring that header size is for a single header The docstring for the header size field currently says "The total number of Bytes used by the part headers", but the size is about a single header, so let's change it to "header".
Wed, 10 Jun 2015 14:47:24 -0700 bundle2: rename duplicate handlepushkeyreply to handleobsmarkerreply
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Jun 2015 14:47:24 -0700] rev 25506
bundle2: rename duplicate handlepushkeyreply to handleobsmarkerreply The function was only called through the parthandlermapping dict, so it was confusing but safe in practice.
Sun, 07 Jun 2015 15:49:57 -0700 changegroup: remove 'getchangegroupraw' function
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:49:57 -0700] rev 25505
changegroup: remove 'getchangegroupraw' function There is no remaining caller for this function.
Sun, 07 Jun 2015 15:49:17 -0700 exchange: expand usage of getchangegroupraw
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:49:17 -0700] rev 25504
exchange: expand usage of getchangegroupraw The 'getchangegroupraw' is very simple (two lines) so we inline it in its only caller. This exposes the 'outgoing' object of the part generator function, allowing us to add information on the number of changesets contained in the part in a later changeset. Such information is useful for progress bar.
Sun, 07 Jun 2015 15:47:07 -0700 getbundle: have a single getchangegroupraw call site
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:47:07 -0700] rev 25503
getbundle: have a single getchangegroupraw call site Having a single call site will simplify the code and help with coming refactoring.
Wed, 27 May 2015 22:25:51 -0700 phases: abort the whole push if phases fail to update (BC)
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 27 May 2015 22:25:51 -0700] rev 25502
phases: abort the whole push if phases fail to update (BC) When using bundle2, the phase pushkey parts are now made mandatory. As a result, failure to update the bookmark server side will result in the transaction being aborted.
Wed, 27 May 2015 22:25:33 -0700 bookmarks: abort the whole push if bookmarks fails to update (BC)
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 27 May 2015 22:25:33 -0700] rev 25501
bookmarks: abort the whole push if bookmarks fails to update (BC) When using bundle2, the bookmark's pushkey parts are now made mandatory. As a result failure to update the bookmark server side will result in the transaction being aborted.
Mon, 08 Jun 2015 16:55:21 -0700 httppeer: allow extensions to replace urllib2.Request
Kyle Lippincott <spectral@google.com> [Mon, 08 Jun 2015 16:55:21 -0700] rev 25500
httppeer: allow extensions to replace urllib2.Request The authentication library my extension wants to use requires using a different opener and a different request builder. This change pulls the call to urllib2.Request out so that my extension can replace it just like it can replace urlopener.
Sun, 07 Jun 2015 17:50:56 -0700 progress: move all logic altering the ui object logic in mercurial.ui
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 17:50:56 -0700] rev 25499
progress: move all logic altering the ui object logic in mercurial.ui The ui object can take care of its progress object logic by itself. test-subrepo-recursion is modified because it is a bit sensitive to the "no progress bar" default. It will become unnecessary in the next step when progress will be on by default in core.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip