in current pathauditor implementation, un-normcase()-ed path is
stored into and compared with audit result cache.
this is not efficiency on case insensitive filesystem.
Older publish=True was:
1) Content of Publishing server are seen as public by client.
2) Any changegroup *added* to a publish=True server is public.
New definition are:
1) Content of Publishing server are seen as public by client.
2) Any changegroup *pushed* to a publish=True server is public.
See mercurial/phase.py documentation for exact final behavior
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.
Remote side may add useful information alongside failure return code. For
example "ssl is required". This patch mirror what is done for the unbundle
command.
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.
