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.
Thu, 03 Jan 2013 17:42:25 +0100 subrepo: make 'in subrepo' string easier to find by external tools
Angel Ezquerra <angel.ezquerra@gmail.com> [Thu, 03 Jan 2013 17:42:25 +0100] rev 18297
subrepo: make 'in subrepo' string easier to find by external tools This patch is meant to make it easier for tools that wrap the mercurial output (such as TortoiseHg) to find the "in subrepo MYSUBREPO" string that (since 9e3910db4e78) is appended after subrepo error messages, particularly when the mercurial output is translated to a non-English language. The message remains the same but the '%s' that was used to prepend the original error message in front of the 'in subrepo' string has been moved out of the translatable string. As an example of the usefulness of making it easy to look for "in subrepo MYSUBREPO" strings, TortoiseHg looks for these strings in error messages in order to "linkify them" (i.e. convert "MYSUBREPO" into alink to the corresponding subrepo). The original string made it hard for a tool such as TortoiseHg to look for the translated string on mercurial's output because the translated string contained the error message itself. This meant that a regular expression was required to ignore the error message part. With this change TortoiseHg can just get the translated "(in subrepo %s)" string, substitute %s for the subrepo path (which it gets from the subrepo exception) and simply search for the resulting string (no regular expression needed, or at least a much simpler regular expression could be used). Additionaly, the existing string could lead a translator mistakenly assume that it was possible invert the order of the %s (error and subrepo path) fields, which would not work because the string interpolation was position based.
Thu, 10 Jan 2013 10:35:37 -0800 subrepo: fix python2.4 compatibility after 9aa6bee6e9f9
Brendan Cully <brendan@kublai.com> [Thu, 10 Jan 2013 10:35:37 -0800] rev 18296
subrepo: fix python2.4 compatibility after 9aa6bee6e9f9 super(SubrepoAbort, self).__init__(*args, **kw) raises TypeError: super() argument 1 must be type, not classobj
Thu, 10 Jan 2013 16:25:06 +0000 test-keyword: improve grammar and spelling in branchcache note
Christian Ebert <blacktrash@gmx.net> [Thu, 10 Jan 2013 16:25:06 +0000] rev 18295
test-keyword: improve grammar and spelling in branchcache note See: da9e544c69d6
Thu, 10 Jan 2013 09:43:28 -0500 Merge with stable.
Augie Fackler <raf@durin42.com> [Thu, 10 Jan 2013 09:43:28 -0500] rev 18294
Merge with stable.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip