FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:35:07 +0900] rev 19847
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".
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Sep 2013 14:23:14 +0200] rev 19846
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Sep 2013 14:36:11 +0200] rev 19845
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.
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 01 Oct 2013 16:41:04 -0300] rev 19844
i18n-pt_BR: synchronized with 1aaefba2a3a9
Matt Mackall <mpm@selenic.com> [Tue, 01 Oct 2013 10:44:59 -0700] rev 19843
merge with stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:12:34 +0900] rev 19842
histedit: add more detailed help about "--outgoing"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:12:34 +0900] rev 19841
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.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:26:22 +0900] rev 19840
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Sep 2013 17:42:38 +0200] rev 19839
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Sep 2013 17:31:39 +0200] rev 19838
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Sep 2013 15:52:37 +0200] rev 19837
branchmap: fix blank line position
The blank line was after was after the `if` condition instead of before.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:12:34 +0900] rev 19836
histedit: add more detailed help about "--outgoing"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:12:34 +0900] rev 19835
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.
Alexander Plavin <alexander@plav.in> [Fri, 06 Sep 2013 13:30:58 +0400] rev 19834
hgweb: eliminate extra complexity in process_dates definition
There was an extra anonymous outer function, called immediately. It is removed
in this patch.
Siddharth Agarwal <sid0@fb.com> [Mon, 30 Sep 2013 12:36:26 -0700] rev 19833
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.
Matt Mackall <mpm@selenic.com> [Mon, 30 Sep 2013 12:38:08 -0700] rev 19832
merge with stable
Martin Schröder <martin.schroeder@nerdluecht.de> [Mon, 30 Sep 2013 20:54:39 +0200] rev 19831
i18n-de: fix record prompt (issue4044)
Martin Schröder <martin.schroeder@nerdluecht.de> [Mon, 30 Sep 2013 20:04:03 +0200] rev 19830
i18n-de: synchronized with bd5c1b49d106
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 24 Sep 2013 13:34:12 -0300] rev 19829
i18n-pt_BR: synchronized with bd5c1b49d106
Kevin Bullock <kbullock@ringworld.org> [Fri, 27 Sep 2013 21:54:53 -0500] rev 19828
strip: bring extension description in line with style and copy-edit
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 26 Sep 2013 11:11:39 +0200] rev 19827
strip: rename test-mq-strip into test-strip
And makes it use the strip extension only (except for the part testing mq
interaction)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 26 Sep 2013 23:57:21 +0200] rev 19826
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 26 Sep 2013 23:43:00 +0200] rev 19825
strip: move the strip helper function for mq to strip
The next patch finally move the command. No joke! (hey, this is for issue3824)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 26 Sep 2013 23:32:52 +0200] rev 19824
strip: move checklocalchanges from mq to strip
One more step for issue3824.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 26 Sep 2013 23:12:43 +0200] rev 19823
strip: move checksubstate from mq to strip
One more step for issue3824
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 26 Sep 2013 23:10:11 +0200] rev 19822
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.
David Soria Parra <dsp@experimentalworks.net> [Thu, 26 Sep 2013 14:47:19 +0200] rev 19821
histedit: remove unused parents() call
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 14:16:51 +0200] rev 19820
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 14:07:37 +0200] rev 19819
mq: extract `mq.queue.strip`
It does not depend on `mq.queue` anymore.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 13:41:43 +0200] rev 19818
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).
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 14:10:34 +0200] rev 19817
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).
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 19:34:45 +0200] rev 19816
mq: document repo.mq.qparents
The function is not very complex but writing this doc helped me to check if
I got everything right.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 19:32:53 +0200] rev 19815
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Sep 2013 12:43:14 +0200] rev 19814
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.
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.
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.
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).
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.
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.
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-
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.
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.
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 21:41:01 -0700] rev 19805
largefiles: 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.
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 20:53:14 -0700] rev 19803
merge: standardize error message for dirty subrepo
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 20:50:51 -0700] rev 19802
merge: standardize error message for dirty working dir
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".
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
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.
Siddharth Agarwal <sid0@fb.com> [Mon, 23 Sep 2013 17:43:33 -0700] rev 19798
update: improve error message for clean non-linear update
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.
Alexander Plavin <alexander@plav.in> [Fri, 06 Sep 2013 13:30:57 +0400] rev 19796
paper: edit search hint to include new feature description
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
Matt Mackall <mpm@selenic.com> [Mon, 23 Sep 2013 14:28:01 -0700] rev 19794
debugshell: appease pyflakes
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.
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
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:16:35 -0400] rev 19791
patchbomb: 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
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:15:51 -0400] rev 19789
patch: correct import of email module
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:15:37 -0400] rev 19788
subrepo: move import of xml.minidom.dom to its own line for check-code
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:15:23 -0400] rev 19787
convert: move import of xml.minidom.dom to its own line for check-code
Augie Fackler <raf@durin42.com> [Fri, 20 Sep 2013 10:14:59 -0400] rev 19786
perf: rearrange imports of changelong and manifest to appease check-code
Matt Mackall <mpm@selenic.com> [Mon, 23 Sep 2013 13:26:11 -0700] rev 19785
merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 23 Sep 2013 13:22:28 -0700] rev 19784
tests: fix check-code breakage