When renaming a patch A as B where B was previously qfolded into A and
therefore marked as removed, a versioned MQ would first restore B before
marking it as a copy of A, thus losing A changes. The undelete() call is
probably a left-over, wctx.copy() explicitely handles the case where the
destination is removed.
Also note that status command represents "hg rm b; hg mv a b" as:
A b
a
R a
which explains the first hunk in test-mq-qrename.t.
The original intent was that the largefiles would primarily be in the
repository, with the global cache being only that--a cache. The naming
conventions and actual intent have both strayed. In this first patch, the
naming conventions are switched to match the actual intent, as are the
configuration options.
overrides.py contains several functions that temporarily override
scmutil.match(), which always takes a changectx object as the first
parameter. But these overrides name that parameter either 'repo' or
'ctxorrepo', which is misleading. So rename them to 'ctx' and remove
the special type-sensitive handling of the one called 'ctxorrepo'.
This option allow a strict set of revision to be specified instead of using -s
or -b. Rebase will refuse start if striping rebased changeset will strip non
rebased changeset. Rebase will refuse to work on set with multiple root.
The buildstate function now take a set of revs. Logic related to --source and
--base option have been moved in the main rebase function.
In the process this fixes a bug where the wrong source changeset might be pick.
This explain the changes in hgext/rebase.py
Patch specifications in mq is passed around as a string or None. None is
generally used when no patch has been specified and there thus is nothing to
lookup and the calling code should do something else. One code path did however
pass None all the way to lookup. That case was handled in lookup, but there was
really need for that, it was undocumented, and it used to cause trouble back
when patches was specified as integers.
Change the behavior so that the sender (the "From" header in the notification
mail) in case of the "changegroup" hook is the user that did the first commit
in the changegroup. The option is configurable, if you set "notify.fromauthor"
to "True" in your config, the new behavior is activated. If you do not set the
option, the behavior is as before. The commit adds to an existing test to show
various aspects of the changed behavior.
This fixes a performance issue with 'hg status' when files are specified
on the command-line. Previously, a large amount of largefiles code was
executed, even if files were specified on the command-line and those files
were not largefiles. This patch fixes the problem by first checking if
non-largefiles were specified on the command-line and, just letting the
normal status function handle the case if they were.
On a brand new machine, the execution time for 'hg status filename' on
a repository with largefiles was:
real 0m0.636s
user 0m0.512s
sys 0m0.120s
versus the following (the same repository, with largefiles disabled):
real 0m0.215s
user 0m0.180s
sys 0m0.032s
After this patch, the performance of 'hg status filename' on the same
repository, with largefiles enabled is:
real 0m0.228s
user 0m0.189s
sys 0m0.036s
This performance boost is also true when patterns (rather than specific
files) are specified on the command-line.
In the case where patterns are specified in addition to a file list, we
just defer to the normal codepath in order to not spend extra time
expanding the patterns to just risk having to expand them again later.
I have not tried to produce the bug but here is idea: b2b0622d9e96 stopped
passing the modified files list to commit. This makes commit more fragile since
we better not touch unrelated files by mistake. But putcommit() still applies
file changes before exiting upon ignored revisions. So in theory, we could
apply changes from a skipped branch then commit them as part of another
revision.
This patch makes the sink apply the changes after possibly skipping the
revision. The real fix would be to use svn commit --targets option to pass the
file names in an argument file. Unfortunately, it seems to be bugged in svn
1.7.1:
http://svn.haxx.se/dev/archive-2011-11/0211.shtml
This was unnecessarily verbose: there is no need to unlink the file
when we open it for write anyway, and there is no need to check if the
file exists after we created it.
Most of the code paths in mq would always pass patch specifications as a
string. Patches can be specified by their index, but one code path passed that
(through pop) to lookup as an integer - all other code paths used a string.
Unfortunately pop and lookup (like many other parts of mq) used the boolean
value of the patch specification to see if it was None, and they would thus
incorrectly handle patch 0 as None.
This patch makes the code comply with the actual internal duck typing of patch
specifications: patch indices must be encoded as strings. The (now) unused code
for partial and thus incorrect handling of indices as integers is removed.
This is mainly about keeping code under the 80-column limit with as
few backslashes as possible. I am deliberately not making any logic or
behaviour changes here and have restrained myself to a few "peephole"
refactorings.
- tweak wording of some error messages
- use consistent capitalization
- always say 'largefile', not 'lfile'
- fix I18N problems
- only raise Abort for errors the user can do something about
- fix some ungrammatical/unclear/incorrect comments/docstrings
- rewrite some really unclear comments/docstrings
- make formatting/style more consistent with the rest of Mercurial
(lowercase without period unless it's really multiple sentences)
- wrap to 75 columns
- always say "largefile(s)", not "lfile(s)" (or "big files")
- one space between sentences, not two
You can get into trouble if you commit, update back to an older
changeset, and then rollback. The update removes your valuable changes
from the working dir, then rollback removes them history. Oops: you've
just irretrievably lost data running nothing but core Mercurial
commands. (More subtly: rollback from a shared clone that was already
at an older changeset -- no update required, just rollback from the
wrong directory.)
The fix assumes that only "commit" transactions have irreplaceable
data, and allows rolling back non-commit transactions as always. But
when rolling back a commit, check that the working dir is checked out
to tip, i.e. the changeset we're about to destroy. If not, abort. You
can get back the old (dangerous) behaviour with --force.
If Python interpreter was built under Linux 3.x kernel, it reports
sys.platform to be 'linux3' (it is fixed for Python 3, but not for 2.x).
This cancels building inotify extension, which was built only for 'linux2'
platform. Improved test checks if sys.platform begins with 'linux', and together
with test for kernel version to be greater than 2.6 it seems to cover all known
cases.
This bug may be caused by file subgraphs have more than two parents
per node. I have no idea if this fix is correct as the graphlog code
is mysterious, but it seems to be fine on the available test case.
A Mercurial repo signals a file is deleted by raising IOError when the
file's data is requested. This IOError is normally caught by
localrepository.commitctx. With the eol extension enabled and EOL
mappings in place, the eolrepo subclass should ignore IOError because
a deleted file has no line endings to process.
This issue exhibited itself when performing an incremental hg convert
of a revision with deleted files to a repo with an existing .hgeol
file.
util.checkwinfilename() and util.checkosfilename() are wrapped.
The former, used by scmutil, is not friendly for Shift_JIS bytes.
The latter is an dynamic alias of checkwinfilename() used by other
modules.
less with the -R option only supports ANSI color codes, and terminfo
mode issue non-ANSI color codes (depending on the database). The -r
option can work around this, but there are users currently using the
-R option, and defaulting to terminfo would break colorization in less
for them without warning.
The new behavior was breaking existing tools that relied on a sequence such as
this:
1) start with a dirty working copy
2) qimport some patch
3) try to qpush it
4) old behavior would fail at this point due to outstanding changes.
(new behavior would only fail if the outstanding changes and the patches
changes intersect)
5) innocent user qrefreshes, gets his local changes in the imported patch
It's worth considering if we can move this behavior to -f in the future.
The most appropriate context is not always clearly defined. The obvious cases:
For working directory commands, we use None
For commands (eg annotate) with single revs, we use that revision
The less obvious cases:
For commands (eg status, diff) with a pair of revs, we use the second revision
For commands that take a range (like log), we use None
Because q.refresh() changes nodeid, .hg/patches/status gets invalid until
q.savedirty(). This patch changes mq not to unlock repository of incomplete
state.
There is now only peer scheme lookup. Repository lookup goes through
peer scheme lookup. When peer and repo types are finally separated,
repo lookup will use peer.local() to get a repository object.
The underbar is dropped so that extensions can patch the table.
