Sat, 18 Oct 2014 18:05:10 -0500 merge with i18n stable 3.2-rc
Matt Mackall <mpm@selenic.com> [Sat, 18 Oct 2014 18:05:10 -0500] rev 23050
merge with i18n
Mon, 13 Oct 2014 14:46:50 +0100 i18n-ru: synchronized with 6b4dc7968bf0 stable
Alexander Sauta <demosito@gmail.com> [Mon, 13 Oct 2014 14:46:50 +0100] rev 23049
i18n-ru: synchronized with 6b4dc7968bf0
Sat, 18 Oct 2014 18:04:31 -0500 merge default into stable for 3.2 freeze stable
Matt Mackall <mpm@selenic.com> [Sat, 18 Oct 2014 18:04:31 -0500] rev 23048
merge default into stable for 3.2 freeze
Fri, 17 Oct 2014 02:17:36 -0700 hook: schedule run "b2x-transactionclose" for after lock release
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 02:17:36 -0700] rev 23047
hook: schedule run "b2x-transactionclose" for after lock release Hooks that run after the transaction need to be able to touch the repository. So we need to run them after the lock release. This is similar to what the "changegroup" hook is doing in the `addchangegroup` function.
Fri, 17 Oct 2014 15:25:32 -0700 repoview: issue a special message when filtering hidden changesets
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 15:25:32 -0700] rev 23046
repoview: issue a special message when filtering hidden changesets Hidden changesets are by far the most common error case and is the only one[1] that can reach the user. We move to a friendlier message with a hint about how to access the data anyway. We should probably point to a help topic instead but we do not have such a topic yet. Example of the new output abort: hidden revision '4'! (use --hidden to access hidden revisions) [1] Actually, filtering from "served" can also reach the user during certain exchange operations.
Fri, 17 Oct 2014 15:54:43 -0700 repoview: include the filter name in filtered revision error messages
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 15:54:43 -0700] rev 23045
repoview: include the filter name in filtered revision error messages This will help user to debug. A more precise message will be issued for the most common case ("visible" filter) in the next changesets. example output: - abort: filtered revision '4'! + abort: filtered revision '4' (not in 'visible' subset)!
Wed, 15 Oct 2014 05:08:56 +0200 largefiles: inline redundant toname function in status
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Oct 2014 05:08:56 +0200] rev 23044
largefiles: inline redundant toname function in status Simpler and an optimization.
Wed, 15 Oct 2014 05:08:56 +0200 largefiles: inline redundant inctx function in status
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Oct 2014 05:08:56 +0200] rev 23043
largefiles: inline redundant inctx function in status
Fri, 17 Oct 2014 18:56:12 +0200 ssl: only use the dummy cert hack if using an Apple Python (issue4410)
Mads Kiilerich <madski@unity3d.com> [Fri, 17 Oct 2014 18:56:12 +0200] rev 23042
ssl: only use the dummy cert hack if using an Apple Python (issue4410) The hack for using certificate store in addition to the provided CAs resides in Apple's OpenSSL. Apple's own Pythons will use it, but other custom built Pythons might use a custom built OpenSSL without that hack and will fail when exposed to the dummy cacert introduced in d7f7f1860f00. There do not seem to be a simple way to check from Python if we are using a patched OpenSSL or if it is an Apple OpenSSL. Instead, check if the Python executable resides in /usr/bin/python* or in /System/Library/Frameworks/Python.framework/ and assume that all Pythons found there will be native Pythons using the patched OpenSSL. Custom built Pythons will not get the benefit of using the CAs from the certificate store.
Wed, 15 Oct 2014 05:08:56 +0200 largefiles: move initialization of standins variable to clarify its "scope"
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Oct 2014 05:08:56 +0200] rev 23041
largefiles: move initialization of standins variable to clarify its "scope"
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip