When largefiles is enabled, commands on large repositories which don't
require largefiles could be slowed down substantially. Disable
checking this for every command.
The code was using the size of a symlink's target, thus wrongly making symlinks
to large files into largefiles themselves. This can be demonstrated by
deleting the symlink and then doing an 'hg up' or 'hg up -C' to restore the
symlink.
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.
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.
