Wed, 25 Sep 2013 11:24:43 +0200 mq: extract checksubstate from the queue class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 11:24:43 +0200] rev 19813
mq: extract checksubstate from the queue class This function does not need any of the the `mq.queue` method or attributes. It is indirectly used by the `strip` command. We are trying to extract this command in a standalone extension as discussed in issue issue3824.
Wed, 25 Sep 2013 12:28:40 +0200 mq: simplifies the refresh hint in checklocalchanges
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 12:28:40 +0200] rev 19812
mq: simplifies the refresh hint in checklocalchanges The `checklocalchanges` function in the `mq.queue` class takes a `refresh` argument that changes the error message of raised exception. When refresh is `True` the exception message is "local changes found, refresh first" otherwise, the message is just "local changes found". This changeset is the first of a series that extract `strip` into a standalone extension (as discussed in issue3824). This `checklocalchanges` function is indirectly used by the strip command. But in a standalone strip extension the concept of "refresh first" has no sense. In practice, When used in the context of the strip commands `refresh`'s value is always `False`. So my final goal is a be able to extract the `checklocalchanges` logic in a standalone extension but to keep the part related to "refresh first" in the mq extension. However the refresh handling is deeply entangled into the `checklocalchanges` code. It is handled as low a possible at the point we raise the exception. So we moves handling of refresh upper in the `checklocalchanges` code. This will allow the extraction of a simple version in the strip extension while mq can still inject its logic when needed. Two helper functions `localchangesfound` and `localchangedsubreposfound` died in the process they are replaced by simple raise lines.
Fri, 06 Sep 2013 00:38:28 +0200 merge: let the user choose to merge, keep local or keep remote subrepo revisions
Angel Ezquerra <angel.ezquerra@gmail.com> [Fri, 06 Sep 2013 00:38:28 +0200] rev 19811
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 50d721553198cea51c30f53b76d41dc919280097 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
Tue, 24 Sep 2013 15:10:32 -0400 python2.4: fix imports of sub-packages of the email package
Augie Fackler <raf@durin42.com> [Tue, 24 Sep 2013 15:10:32 -0400] rev 19810
python2.4: fix imports of sub-packages of the email package These all have an obvious comment so if/when we finally ditch Python 2.4 we can eradicate them easily.
Fri, 20 Sep 2013 09:16:07 -0400 httpconnection: properly inject ssl_wrap_socket into httpclient (issue4038)
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 09:16:07 -0400] rev 19809
httpconnection: properly inject ssl_wrap_socket into httpclient (issue4038) This causes httpclient to use the same SSL settings as the rest of Mercurial, and adds an easy extension point for later modifications to our ssl handling.
Fri, 20 Sep 2013 09:15:43 -0400 sslutil: make keyfile and certfile arguments consistent between 2.6+ and 2.5-
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 09:15:43 -0400] rev 19808
sslutil: make keyfile and certfile arguments consistent between 2.6+ and 2.5-
Fri, 20 Sep 2013 09:15:09 -0400 httpclient: import 4bb625347d4a to provide SSL wrapper injection
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 09:15:09 -0400] rev 19807
httpclient: import 4bb625347d4a to provide SSL wrapper injection This lets us inject our own ssl.wrap_socket equivalent into httpclient, which means that any changes we make to our ssl handling can be *entirely* on our side without having to muck with httpclient, which sounds appealing. For example, an extension could wrap sslutil.ssl_wrap_socket with an api-compatible wrapper and then tweak SSL settings more precisely or use GnuTLS instead of OpenSSL.
Thu, 19 Sep 2013 16:29:00 -0400 sslutil: add a config knob to support TLS (default) or SSLv23 (bc) (issue4038)
Augie Fackler <raf@durin42.com> [Thu, 19 Sep 2013 16:29:00 -0400] rev 19806
sslutil: add a config knob to support TLS (default) or SSLv23 (bc) (issue4038) Prior to this change, we default to SSLv23, which is insecure because it allows use of SSLv2. Unfortunately, there's no constant for OpenSSL to let us use SSLv3 or TLS - we have to pick one or the other. We expose a knob to revert to pre-TLS SSL for the user that has an ancient server that lacks proper TLS support.
Mon, 23 Sep 2013 21:41:01 -0700 largefiles: standardize error message for dirty working dir
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 21:41:01 -0700] rev 19805
largefiles: standardize error message for dirty working dir
Mon, 23 Sep 2013 21:31:37 -0700 cmdutil.bailifchanged: standardize error message for dirty working dir
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 21:31:37 -0700] rev 19804
cmdutil.bailifchanged: standardize error message for dirty working dir This affects rebase, graft, histedit, and other similar commands.
Mon, 23 Sep 2013 20:53:14 -0700 merge: standardize error message for dirty subrepo
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 20:53:14 -0700] rev 19803
merge: standardize error message for dirty subrepo
Mon, 23 Sep 2013 20:50:51 -0700 merge: standardize error message for dirty working dir
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 20:50:51 -0700] rev 19802
merge: standardize error message for dirty working dir
Mon, 23 Sep 2013 20:33:02 -0700 update: standardize error message for dirty update --check
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 20:33:02 -0700] rev 19801
update: standardize error message for dirty update --check This and following patches will standardize the error message for dirty working directories to "uncommitted changes".
Mon, 23 Sep 2013 20:08:52 -0700 update: improve error message for dirty non-linear update with rev
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 20:08:52 -0700] rev 19800
update: improve error message for dirty non-linear update with rev
Mon, 23 Sep 2013 20:07:30 -0700 update: add error message for dirty non-linear update with no rev
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 20:07:30 -0700] rev 19799
update: add error message for dirty non-linear update with no rev Previously, the error message for a dirty non-linear update was the same (and relatively unhelpful) whether or not a rev was specified. This patch and an upcoming one will introduce separate, more helpful hints.
Mon, 23 Sep 2013 17:43:33 -0700 update: improve error message for clean non-linear update
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 17:43:33 -0700] rev 19798
update: improve error message for clean non-linear update
Mon, 23 Sep 2013 19:02:32 -0700 pull: for pull --update with failed update, print hint if any
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 19:02:32 -0700] rev 19797
pull: for pull --update with failed update, print hint if any An upcoming patch will add a hint to the abort message, and we don't want to lose that here.
Fri, 06 Sep 2013 13:30:57 +0400 paper: edit search hint to include new feature description
Alexander Plavin <alexander@plav.in> [Fri, 06 Sep 2013 13:30:57 +0400] rev 19796
paper: edit search hint to include new feature description
Thu, 25 Jul 2013 01:12:25 +0400 paper: define searchhint message in map file and use it in other templates
Alexander Plavin <alexander@plav.in> [Thu, 25 Jul 2013 01:12:25 +0400] rev 19795
paper: define searchhint message in map file and use it in other templates
Mon, 23 Sep 2013 14:28:01 -0700 debugshell: appease pyflakes
Matt Mackall <mpm@selenic.com> [Mon, 23 Sep 2013 14:28:01 -0700] rev 19794
debugshell: appease pyflakes
Fri, 20 Sep 2013 10:18:09 -0400 check-code: new rule to forbid imports of a.b on the same line as other imports
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:18:09 -0400] rev 19793
check-code: new rule to forbid imports of a.b on the same line as other imports This style of import can trip up 2to3 and cause it to produce invalid files if one of the imports is supposed to be a relative import. This prevents that behavior, and in the process exposed a lot of silly import errors related to the email module.
Fri, 20 Sep 2013 10:16:55 -0400 notify: correct import of email module, sort stdlib modules to top
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:16:55 -0400] rev 19792
notify: correct import of email module, sort stdlib modules to top
Fri, 20 Sep 2013 10:16:35 -0400 patchbomb: correct import of email module
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:16:35 -0400] rev 19791
patchbomb: correct import of email module
Fri, 20 Sep 2013 10:16:02 -0400 mail: correct import of email module
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:16:02 -0400] rev 19790
mail: correct import of email module
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 +30000 tip