This makes it possible to pass keepbranches and extrafn to rebase at
the same time, although nobody uses that functionality presently. This
is a precursor to keeping graft metadata.
We allow shelving of of changes on top of a MQ repository. MQ will
not allow repository changes on top of applied patches. We introduce
checkapplied in MQ to bypass this check.
Use a more condensed and mercurial-like output format for shelve listing.
We don't prefix the message with 'shelved from...' anymore as our default
name contains the branch name or the user used his own name. To avoid
just printing the last commit message, we drop writing the description
to stdout.
old output:
default [1s ago] shelved from default (01ba9745): create conflict
new output:
default (1s ago) create conflict
This extension saves shelved changes using a temporary draft commit,
and bundles the temporary commit and its draft ancestors, then
strips them.
This strategy makes it possible to use Mercurial's bundle and merge
machinery to resolve conflicts if necessary when unshelving, even
when the destination commit or its ancestors have been amended,
squashed, or evolved. (Once a change has been unshelved, its
associated unbundled commits are either rolled back or stripped.)
Storing the shelved change as a bundle also avoids the difficulty
that hidden commits would cause, of making it impossible to amend
the parent if it is a draft commits (a common scenario).
Although this extension shares its name and some functionality with
the third party hgshelve extension, it has little else in common.
Notably, the hgshelve extension shelves changes as unified diffs,
which makes conflict resolution a matter of finding .rej files and
conflict markers, and cleaning up the mess by hand.
We do not yet allow hunk-level choosing of changes to record.
Compared to the hgshelve extension, this is a small regression in
usability, but we hope to integrate that at a later point, once the
record machinery becomes more reusable and robust.
Before this patch, "hg summary" may fail, when there is inconsistent
rebase state: for example, the root of rebase destination revisions
recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
summary hook, and treat such state as "broken".
Before this patch, "rebase --abort"/"--continue" may fail, when rebase
state is inconsistent: for example, the root of rebase destination
revisions recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
abort/continue, and treat such state as "broken".
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".
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.
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.
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 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.
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.
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).
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).
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.
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.
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.
Before this patch, there is no explicit description that argument is
treated as the URL of the destination repository when "--outgoing" is
specified.
This patch adds description about "histedit --outgoing" to command
help of it.
Before this patch, there is no explicit description that histedit
edits changesets between specified ancestor and the parent of the
working directory: users may notice it by error message "REV is not an
ancestor of working directory".
This patch adds description about basic histedit function to command
help of it.
This patch uses term "ancestor" instead of "parent", because it seems
to be more suitable, and almost all (error) messages already use it.
Similar to issue4009, 2.7 will force people to abort histedits before
doing interesting things. Without this fix, people with histedit
sessions they wandered away from before upgrading to 2.7 could clobber
their working copy for no reason.
Before this patch, if largefiles extension is enabled once in any of
target repositories, commands handling multiple repositories at a time
like below misunderstand that "largefiles" feature is supported also
in all other local repositories:
- clone/pull from or push to localhost
- recursive execution in subrepo tree
This patch registers "featuresetup()" into "featuresetupfuncs" of
"localrepository" to support "largefiles" features only in
repositories enabling largefiles extension, instead of adding
"largefiles" feature to class variable "_basesupported" of
"localrepository".
This patch also adds checking below to the largefiles specific class
derived from "localrepository":
- push to localhost: whether features supported in the local(= dst)
repository satisfies ones required in the remote(= src)
This can prevent useless looking up in the remote repository, when
supported and required features are mismatched: "push()" of
"localrepository" also checks it, but it is executed after looking up
in the remote.
Before this patch, all localrepositories support same features,
because supported features are managed by the class variable
"supported" of "localrepository".
For example, "largefiles" feature provided by largefiles extension is
recognized as supported, by adding the feature name to "supported" of
"localrepository".
So, commands handling multiple repositories at a time like below
misunderstand that such features are supported also in repositories
not enabling corresponded extensions:
- clone/pull from or push to localhost
- recursive execution in subrepo tree
"reposetup()" can't be used to fix this problem, because it is invoked
after checking whether supported features satisfy ones required in the
target repository.
So, this patch adds the set object named as "featuresetupfuncs" to
"localrepository" to manage hook functions to setup supported features
of each repositories.
If any functions are added to "featuresetupfuncs", they are invoked,
and information about supported features is managed in each
repositories individually.
This patch also adds checking below:
- pull from localhost: whether features supported in the local(= dst)
repository satisfies ones required in the remote(= src)
- push to localhost: whether features supported in the remote(= dst)
repository satisfies ones required in the local(= src)
Managing supported features by the class variable means that there is
no difference of supported features between each instances of
"localrepository" in the same Python process, so such checking is not
needed before this patch.
Even with this patch, if intermediate bundlefile is used as pulling
source, pulling indirectly from the remote repository, which requires
features more than ones supported in the local, can't be prevented,
because bundlefile has no information about "required features" in it.
This saves us a relatively superfluous status check for pull --rebase (if
rebase runs, it'll check for a clean working directory anyway), and brings hg
pull --rebase closer to hg pull && hg rebase.
This is a behavior change because pull --rebase with a dirty working directory
will now abort after performing the pull rather than before.
Up until now applying or unapplying a patch that modified .hgsubstate would not
work as expected because it would not update the subrepos according to the
.hgsubstate change. This made it very easy to lose subrepo changes when using
mq.
This revision also changes the test-mq-subrepo test so that on the qpop / qpush
tests. We no longer use the debugsub command to check the state of the subrepos
after the qpop and qpush operations. Instead we directly run the id command on
the subrepos that we want to check. The reason is that using the debugsub
command is misleading because it does not really check the state of the subrepos
on the working directory (it just returns what the change that is specified on a
given revision). Because of this the tests did not detect the problem that this
revision fixes (i.e. that applying a patch did not update the subrepos to the
corresponding revisions).
# HG changeset patch
# User Angel Ezquerra <angel.ezquerra@gmail.com>
# Date 1376350710 -7200
# Tue Aug 13 01:38:30 2013 +0200
# Node ID 60897e264858cdcd46f89e27a702086f08adca02
# Parent 2defb5453f223c3027eb2f7788fbddd52bbb3352
mq: update subrepos when applying / unapplying patches that change .hgsubstate
Up until now applying or unapplying a patch that modified .hgsubstate would not
work as expected because it would not update the subrepos according to the
.hgsubstate change. This made it very easy to lose subrepo changes when using
mq.
This revision also changes the test-mq-subrepo test so that on the qpop / qpush
tests. We no longer use the debugsub command to check the state of the subrepos
after the qpop and qpush operations. Instead we directly run the id command on
the subrepos that we want to check. The reason is that using the debugsub
command is misleading because it does not really check the state of the subrepos
on the working directory (it just returns what the change that is specified on a
given revision). Because of this the tests did not detect the problem that this
revision fixes (i.e. that applying a patch did not update the subrepos to the
corresponding revisions).
It was possible to apply, unapply, fold, patches (etc) with modified subrepos,
which resulted in surprising behavior. For example it was easy to apply a patch
with a modified subrepo, and then the refresh it and accidentally end up
including the modified subrepo on the refreshed patch.
A test has been added to verify this new check.
# HG changeset patch
# User Angel Ezquerra <angel.ezquerra@gmail.com>
# Date 1375742979 -7200
# Tue Aug 06 00:49:39 2013 +0200
# Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124
# Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7
mq: look for modified subrepos when checking for local changes
It was possible to apply, unapply, fold, patches (etc) with modified subrepos,
which resulted in surprising behavior. For example it was easy to apply a patch
with a modified subrepo, and then the refresh it and accidentally end up
including the modified subrepo on the refreshed patch.
A test has been added to verify this new check.
Refactoring in c253d4a7ab54 made this comment meaningless. The node
gotten by "discovery.findcommonoutgoing()" is hexlified in "between()"
by "repo.set('%n::%n', old, new)".
Before this patch, there is no explicit description that argument is
treated as the URL of the destination repository when "--outgoing" is
specified.
This patch adds description about "histedit --outgoing" to command
help of it.
Before this patch, there is no explicit description that histedit
edits changesets between specified ancestor and the parent of the
working directory: users may notice it by error message "REV is not an
ancestor of working directory".
This patch adds description about basic histedit function to command
help of it.
This patch uses term "ancestor" instead of "parent", because it seems
to be more suitable, and almost all (error) messages already use it.
Convert, for example, has loops like this:
for revision in source_repo:
progress(revisions)
for file in revision:
progresss(file)
Prior to this change, we would start showing the file-level progress
when we encountered a big revision, and then we'd get stuck in showing
file-progress instead of revision progress, often producing many many
instantly-completing progress bars rather than the actually-helpful
top-level revisions bar.
The refactoring of all the context objects allows us to simply pass a basectx
to the __new__ constructor and have it return the same object without
allocating new memory.
This also removes the need to import the context module.
The tests contain a couple corner cases where workarounds are now
required. Strictly speaking, these are behavior regressions, but of an
extremely obscure and marginal sort. Commits or updates in the middle
of a histedit would have almost always been fairly serious user error.
This splits churn email aliases from the right, to enable incorrectly-specified
addresses that include equal signs to be mapped to correct addresses. This
will enable aliasing of bad addresses (typically typos) such as:
sername=myusername
that appear in the churn output through a churn alias such as:
sername=myusername = myusername
whereas previously splitting from the left would not enable this behavior.
The 'copynode' was looked up in self.keep as if it was a changeset node. It is
however a filelog node, and self.keep would thus fail if it actually looked at
its parameter ... which it only did if a startrev was specified.
Instead we now don't check the copy node - we don't have to. It must have been
copied from one of the parents, and we already check whether one of the parents
have the copy source.
We could perhaps use linkrev to see if the corresponding changeset was
converted ... but that would sometimes be wrong.
The existing test of this was wrong - now it is better, but it seems like it
exposes a 'log' issue.
The same `queue` object should be used in all situations. This allows to store
global states on the object (like the reworked shelve extension plans to). The
queue object does not need to be distinct for all possible views (no reference
to the repo/view used at creation time) it's even a bit surprising that mq still
works with the current code.
When a file was renamed in the very first changeset being histedited,
the rename was not detected. Consider a history like this:
0 base: add a.txt
1 first: rename a.txt to b.txt
2 last: edit b.txt
When 1 and 2 are edited, copies.pathcopies(first, last) correctly
returns that nothing was renamed. We must instead use
copies.pathcopies(first, last) to detect the initial rename.
In the tests some scripts call reposetup with the base ui instead of the
one the extensions have modified. This causes an exception in
blackbox.reposetup since it expected a method to be there. So I just
check for it first. This only happened when the blackbox extension
was enabled during tests.
Before this patch, largefiles extension checks unknown files in the
working directory always case sensitively.
This causes failure in updating from the revision X consisting of
'.hglf/A' (and "A" implicitly) to the revision Y consisting of 'a'
(not ".hglf/A") on case insensitive filesystem, because "A" in the
working directory is treated as colliding against and different from
'a' on the revision Y.
This patch uses "repo.dirstate.normalize()" to check unknown files
with case awareness of the filesystem.
Before this patch, largefiles extension always unlinks largefiles
untracked on the target context in merging/updating after updating
working directory.
For example, it is assumed that the revision X consists of ".hglf/A"
(and "A" implicitly) and revision Y consists of "a" (not ".hglf/A").
In the case of updating from X to Y, largefiles extension tries to
unlink "A" after updating "a" in working directory. This causes
unexpected unlinking "a" on the case insensitive filesystem.
This patch checks existence of the file in the working context with
case awareness of the filesystem to prevent from such unexpected
unlinking.
"lfcommands._updatelfile()" also unlinks target file in the case
"largefile is tracked in the target context, but fails to be fetched".
This patch doesn't apply "repo.dirstate.normalize()" in this case,
because it should be already ensured in the manifest merging that
there is no normal file colliding against any largefiles.
The cvsps.py:getrepopath suffers from a string parsing bug (it returns
"user@server/path/to/repository" if the CVSROOT is given like this:
":pserver:user@server/path/to/repository" ), which gives returnes the wrong
value becouse cvsps.py fails to strip the prefix from filenames.
With this patch for the same input we get the correct repo path that is:
"/path/to/repository"
After 08202d1ef738 I see:
$ hg id -q
largefiles: repo method 'commit' appears to have already been wrapped by another extension: largefiles may behave incorrectly
largefiles: repo method 'push' appears to have already been wrapped by another extension: largefiles may behave incorrectly
3bd0c95ec1bf
The warning is bad:
* The message gives no hint what the problem is and how it can be resolved.
The message is useless.
* Largefiles do have its share of problems, but I don't think I ever have seen
a problem where this warning would have helped. The 'may' in the warning
seems like an exaggeration of the risk. Having largefiles enabled in
combination with for instance mq, hggit and hgsubversion causes a warning
(depending on the configuration order) but do not cause problems. Extensions
might of course be incompatible, but they can be that in many other ways.
The check and the message are incorrect.
It would thus be better to remove the check and the warning completely.
Before 08202d1ef738 the check always failed. That change made the check work
more like intended ... but the intention was wrong. This change will thus also
back that change out.
Previously, colorui assumed that it would only be called when mode wasn't
None. 255b770b2eff changed that, so now colorui needs to care about whether it
should colorize output.
If enabled, log rotation prevents the amount of space used by the
blackbox log from growing without bound. This becomes important in
cases where there are a lot of busy repositories managed by humans
and automation on many machines.
In large deployments, we cannot reasonably track all the repos where
blackbox logs need to be managed, so it is safer to have blackbox
manage its own logs than to move responsibility to an external tool
such as logrotate.
This change adds two configuration keys:
* blackbox.maxsize is the maximum allowable size of the current log
* blackbox.maxfiles is the number of log files to maintain
