When a user requested a diff between a revision (r1) that contained a subrepo
and another (r2) that did not, mercurial would crash if r1 was specified before
r2 but would execute the diff otherwise. This fixes this behavior by skipping
the missing subrepo in the diff.
The largefiles extension prevents users from adding a normal file
named 'foo' if there is already a largefile with the same name.
However, there was a loop-hole: when merging, it was possible to bring
in a normal file named 'foo' while also having a '.hglf/foo' file.
This patch fixes this by extending the manifest merge to deal with
these kinds of conflicts. If there is a normal file 'foo' in the
working copy, and the other parent brings in a '.hglf/foo' file, then
the user will be prompted to keep the normal file or the largefile.
Likewise for the symmetric case where a normal file is brought in via
the second parent. The prompt looks like this:
$ hg merge
foo has been turned into a largefile
use (l)argefile or keep as (n)ormal file?
After the merge, either the '.hglf/foo' file or the 'foo' file will
have been deleted. This would cause status to return output like:
$ hg status
M foo
R foo
To fix this, the lfiles_repo.status method is changed so that a
removed normal file isn't shown if there is largefile with the same
name, and vice versa for largefiles.
ui.quiet and ui.debugflag are not initialized during uisetup and
reposetup. progressui is always initialized, therefore we have to check
during write() if ui.quiet is set or not.
If a largefile is introduced on the branch that is merged into the
working copy, then 'hg status' would abort with an error like:
$ hg status
abort: .hglf/foo@33fdd332ec: not found in manifest!
The problem was that the largefiles status code only looked in the
first parent for the largefile. Largefiles are now always reported as
modified if they don't exist in the first parent -- this matches the
behavior of localrepo.status for normal files.
Before:
>>> str(url('file:///c:/tmp/foo/bar'))
'file:c%3C/tmp/foo/bar'
After:
>>> str(url('file:///c:/tmp/foo/bar'))
'file:///c%3C/tmp/foo/bar'
The previous behaviour had no effect on mercurial itself (clone command for
instance) because we fortunately called .localpath() on the parsed URL.
hgsubversion was not so lucky and cloning a local subversion repository on
Windows no longer worked on the default branch (it works on stable because
2b62605189dc defeats the hasdriveletter() test in url class).
I do not know if the %3C is correct or not but svn accepts file:// URLs
containing it. Mads fixed it in 2b62605189dc, so we can always backport should
the need arise.
A convert run with a branchmap made with
echo default namedbranch > branchmap
on Windows fails silently and surprisingly; it actually
adds a space after 'namedbranch', so it ends up mapping
"default namedbranch" to "".
This also affects splicemaps, since the same parser is used
for both.
I modified check-code.py "$?" detection because I thought my use was legit, we
cannot test exit status of pipelines commands except for the last one without
this. So it now tolerates "[$?" which is unlikely to be added by mistake.
Tested on:
- OSX + svn 1.7.1
- Linux + svn 1.6.12
The contract for repo.destroyed() is that it is called whenever
changesets are destroyed, either by strip or by rollback. That
contract was inadvertently broken in 6c30b131b2ae, when we made a
chunk of code conditional on destroying one of the working dir's
parents. Oops: it doesn't matter *which* changesets are destroyed or
what their relationship is to the working dir, we should call
repo.destroyed() whenever we destroy changesets.
An alias for 'log' was stored in the same command table as
'^log|history'. If the hash function happens to give the latter first,
the alias is effectively ignored when matching 'log'.
As of svn 1.7, many svn calls expect "canonical" paths. In theory, we should
call svn.core.*canonicalize() on all paths before passing them to the API.
Instead, we assume the base url is canonical and copy the behaviour of svn URL
encoding function so we can extend it safely with new components.
Calling branchmap() or similar on a bundlerepo would write the bundle-augmented
branch cache to disk, requiring a subsequent expensive rebuild when the repo
is used without the bundle.
Before, it was possible to create a
.hg/largefiles/hash
file with truncated content, i.e., content where
SHA-1(content) != hash
This breaks the fundamental invariant in largefiles that the file
content for files in .hg/largefiles hash to the filename.
current lfconvert implementation uses combination of "ui.config()" and
"str.split(' ')" to get largefiles.patterns configuration.
but it can not handle multiline configuration in hgrc files correctly.
lfconvert should use "ui.configlist()" instead of it, as same as
override_add does.
OS X does the following transformation on paths for comparisons:
a) 8-bit strings are decoded as UTF-8 to UTF-16
b) undecodable bytes are percent-escaped
c) accented characters are converted to NFD decomposed form, approximately
d) characters are converted to _lowercase_ using internal tables
Both (c) and (d) are done using internal tables that vary from release
to release and match Unicode specs to greater or lesser extent. We
approximate these functions using Python's internal Unicode data.
With this change, Mercurial will (in almost all cases) match OS X
folding and not report unknown file aliases for files in UTF-8 or
other encodings.
Operating on a non-existant file can cause both IOError and OSError,
depending on the function used: open raises IOError, os.lstat raises
OSError.
The largefiles code called dirstate.normal, which in turn calls
os.lstat, so OSError is the right exception to catch here.
This help entry didn't try to describe the 'localhost' notation. It described a
non-standard host-less notation where 'local' just was the first part of a
sample relative path. It describe "urls" with relative and absolute paths like:
file://file.txt
file:///tmp/file.txt
file://c:/tmp/file.txt
When hook output redirection is enabled (e.g. when cloning over ssh), hook
output on stdout is redirected to stderr, to prevent the repository data on
stdout from being corrupted.
In certain cases, the redirection could cause part of the repository data to
end up on stderr as well. In case of a clone, this causes:
"abort: consistency error in delta!"
This was seen with a clone over ssh, an outgoing hook present (any
non-python type, e.g. 'pwd'), on certain repositories only,
probably depending on the distribution of the sent data)
This patch updates the hook redirection code to flush stdout before
redirecting, removing the problem.
