histedit: suggest "histedit --abort" for inconsistent histedit state Mercurial earlier than 2.7 allows users to do anything other than starting new histedit, even though current histedit is not finished or aborted yet. So, unfinished (and maybe inconsistent now) histedit states may be left and forgotten in repositories. Before this patch, histedit extension shows the message below, when it detects such inconsistent state: abort: REV is not an ancestor of working directory (update to REV or descendant and run "hg histedit --continue" again) But this message is incorrect, unless old Mercurial is re-installed, because Mercurial 2.7 or later disallows users to update the working directory to another revision. This patch changes the hint message to suggest "hg histedit --abort".

repoview: have unfilteredpropertycache using the underlying cache A `unfilteredpropertycache` is a kind of `propertycache` used on `localrepo` to unsure it will always be run against unfiltered repo and stored only once. As the cached value is never stored in the repoview instance, the descriptor will always be called. Before this patch such calls always result in a call to the `__get__` method of the `propertycache` on the unfiltered repo. That was recomputing a new value on every access through a repoview. We can't prevent the repoview's `unfilteredpropertycache` to get called on every access. In that case the new code makes a standard attribute access to the property. If a value is cached it will be used. The `propertycache` test file have been augmented with test about this issue.

repoview: make propertycache.setcache compatible with repoview Propertycache used standard attribute assignment. In the repoview case, this assignment was forwarded to the unfiltered repo. This result in: (1) unfiltered repo got a potentially wrong cache value, (2) repoview never reused the cached value. This patch replaces the standard attribute assignment by an assignment to `objc.__dict__` which will bypass the `repoview.__setattr__`. This will not affects other `propertycache` users and it is actually closer to the semantic we need. The interaction of `propertycache` and `repoview` are now tested in a python test file.

i18n-pt_BR: synchronized with 1aaefba2a3a9

merge with stable

histedit: add more detailed help about "--outgoing"

histedit: abort if there are multiple roots in "--outgoing" revisions Before this patch, if there are multiple roots in "--outgoing" revisions, result of "histedit --outgoing" depends on the parent of the working directory. It succeeds only when the parent of the working directory is a descendant of the oldest root in "--outgoing" revisions, and fails otherwise. It seems to be ambiguous and difficult for users. This patch makes "histedit --outgoing" abort if there are multiple roots in "--outgoing" revisions always.

discovery: abort also when pushing multiple headed new branch Before this patch, pushing with --new-branch permits to create multiple headed branch on the destination repository. But permitting to create new branch should be different from permitting to create multiple heads on branch. This patch prevents from careless pushing multiple headed new branch, and requires --force to push such branch forcibly.

branchmap: stop looking for stripped branch Since repoview in 2.5 we do not make special call to `branchmap` when stripping. We just recompute the branchmap from a lower subset that still has valid branchmap. So I'm dropping this dead code.

branchmap: remove the droppednodes logic It was unused. note how it is only extended if the list is empty. So it's always empty at the end. We could try to fix that, however this would part of the code is to be removed in the next changeset as we do not run `branchmap` on truncated repo since `repoview` in 2.5.

branchmap: fix blank line position The blank line was after was after the `if` condition instead of before.

histedit: add more detailed help about "--outgoing"

histedit: abort if there are multiple roots in "--outgoing" revisions Before this patch, if there are multiple roots in "--outgoing" revisions, result of "histedit --outgoing" depends on the parent of the working directory. It succeeds only when the parent of the working directory is a descendant of the oldest root in "--outgoing" revisions, and fails otherwise. It seems to be ambiguous and difficult for users. This patch makes "histedit --outgoing" abort if there are multiple roots in "--outgoing" revisions always.

hgweb: eliminate extra complexity in process_dates definition There was an extra anonymous outer function, called immediately. It is removed in this patch.

util.h: backout 06badf7d10dc and 2c9645c0a582 for big-endian breakage getbe32 and putbe32 need to behave differently on big-endian and little-endian systems. On big-endian ones, they should be roughly equivalent to the identity function with a cast, but on little-endian ones they should reverse the order of the bytes. That is achieved by the original definition, but __builtin_bswap32 and _byteswap_ulong, as the names suggest, swap bytes around unconditionally. There was no measurable performance improvement, so there's no point adding extra complexity with even more ifdefs for endianncess.

merge with stable

i18n-de: fix record prompt (issue4044)

i18n-de: synchronized with bd5c1b49d106

i18n-pt_BR: synchronized with bd5c1b49d106

strip: bring extension description in line with style and copy-edit

strip: rename test-mq-strip into test-strip And makes it use the strip extension only (except for the part testing mq interaction)

mq: extract strip function as its standalone extension (issue3824) Strip now lives in its own extension reminder: The extension is surprisingly called `strip`. The `mq` extension force the use of the strip extension when its enabled. This is both necessary for backward compatibility (people expect `mq` to comes with strip) and become some utility function used by `mq` are now in the strip extension.

strip: move the strip helper function for mq to strip The next patch finally move the command. No joke! (hey, this is for issue3824)

strip: move checklocalchanges from mq to strip One more step for issue3824.

strip: move checksubstate from mq to strip One more step for issue3824

mq: prepare a strip extension for extraction Strip will lives in its own extension. The extension is surprisingly called `strip`. (as discussed in issue3824) The `mq` extension force the use of the strip extension when its enabled. This will both necessary for backward compatibility (people expect `mq` to comes with strip) and become some utility function used by `mq` will move in the strip extension.

histedit: remove unused parents() call

mq: have the strip command functionnal on repo without mq This is the last step before being able to extract `strip` in its own extension. The changes are made in mq to allow a move only extraction without touching a line of code.

mq: extract `mq.queue.strip` It does not depend on `mq.queue` anymore.

mq: drop the use of mq.queue.qparent in mq.queue.strip Same as in the previous changeset, rev is never `None`. We can just copy the two relevant lines in in `queue.strip`. This help having `queue.strip` independent from `queue`. One further step toward the extraction of `strip` in an independent extension. (As discussed in issue3824).

mq: drop the use of mq.queue.qparent in mq.strip In this case, rev is never `None`. We can just copy the two relevant lines in in `strip`. This help having `strip` independent from `queue` one further step toward its extraction in an independent extension. (As discussed in issue3824).

mq: document repo.mq.qparents The function is not very complex but writing this doc helped me to check if I got everything right.

mq: use the new checklocalchange in the strip command The strip command never use the `refresh` argument. So we can use the function we just extracted.

mq: extract checklocalchanges from `mq.queue` The core part of `checklocalchanges` is now mq independent. We can extract it in a standalone function to help the extraction of `strip` as discussed in issue3824. A `checklocalchanges` function stay in `mq.queue` with the part related to "refresh first" messages.

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.

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.

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).

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.

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.

sslutil: make keyfile and certfile arguments consistent between 2.6+ and 2.5-

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.

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.

largefiles: standardize error message for dirty working dir

cmdutil.bailifchanged: standardize error message for dirty working dir This affects rebase, graft, histedit, and other similar commands.

merge: standardize error message for dirty subrepo

merge: standardize error message for dirty working dir

update: standardize error message for dirty update --check This and following patches will standardize the error message for dirty working directories to "uncommitted changes".

update: improve error message for dirty non-linear update with rev

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.

update: improve error message for clean non-linear update

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.

paper: edit search hint to include new feature description

paper: define searchhint message in map file and use it in other templates

debugshell: appease pyflakes

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.

notify: correct import of email module, sort stdlib modules to top

patchbomb: correct import of email module

mail: correct import of email module

patch: correct import of email module

subrepo: move import of xml.minidom.dom to its own line for check-code

convert: move import of xml.minidom.dom to its own line for check-code

perf: rearrange imports of changelong and manifest to appease check-code

merge with stable

tests: fix check-code breakage