discovery.findoutgoing used to be a useful hook for extensions like
hgsubversion. This patch reintroduces this version of findcommonincoming
which is meant to be used when computing outgoing changesets.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
The introduction of the new URL parsing code has created a startup
time regression. This is mainly due to the use of url.hasscheme() in
the ui class. It ends up importing many libraries that the url module
requires.
This fix helps marginally, but if we can get rid of the urllib import
in the URL parser all together, startup time will go back to normal.
perfstartup time before the URL refactoring (707e4b1e8064):
! wall 0.050692 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
current startup time (9ad1dce9e7f4):
! wall 0.070685 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
after this change:
! wall 0.064667 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
This is a long desired cleanup and paves the way for new discovery.
To specify subsets for bundling changes, all code should use the heads
of the desired subset ("heads") and the heads of the common subset
("common") to be excluded from the bundled set. These can be used
revlog.findmissing instead of revlog.nodesbetween.
This fixes an actual bug exposed by the change in test-bundle-r.t
where we try to bundle a changeset while specifying that said changeset
is to be assumed already present in the target. This used to still
bundle the changeset. It no longer does. This is similar to the bugs
fixed by the recent switch to heads/common for incoming/pull.
This replaces util.drop_scheme() with url.localpath(), using url.url for
parsing instead of doing it on its own. The function is moved from
util to url to avoid an import cycle.
hg.localpath() is removed in favor of using url.localpath(). This
provides more consistent behavior between "hg clone" and other
commands.
To preserve backwards compatibility, URLs like bundle://../foo still
refer to ../foo, not /foo.
If a URL contains a scheme, percent-encoded entities are decoded. When
there's no scheme, all characters are left untouched.
Comparison of old and new behaviors:
URL drop_scheme() hg.localpath() url.localpath()
=== ============= ============== ===============
file://foo/foo /foo foo/foo /foo
file://localhost:80/foo /foo localhost:80/foo /foo
file://localhost:/foo /foo localhost:/foo /foo
file://localhost/foo /foo /foo /foo
file:///foo /foo /foo /foo
file://foo (empty string) foo /
file:/foo /foo /foo /foo
file:foo foo foo foo
file:foo%23bar foo%23bar foo%23bar foo#bar
foo%23bar foo%23bar foo%23bar foo%23bar
/foo /foo /foo /foo
Windows-related paths on Windows:
URL drop_scheme() hg.localpath() url.localpath()
=== ============= ============== ===============
file:///C:/foo C:/C:/foo /C:/foo C:/foo
file:///D:/foo C:/D:/foo /D:/foo D:/foo
file://C:/foo C:/foo C:/foo C:/foo
file://D:/foo C:/foo D:/foo D:/foo
file:////foo/bar //foo/bar //foo/bar //foo/bar
//foo/bar //foo/bar //foo/bar //foo/bar
\\foo\bar //foo/bar //foo/bar \\foo\bar
Windows-related paths on other platforms:
file:///C:/foo C:/C:/foo /C:/foo C:/foo
file:///D:/foo C:/D:/foo /D:/foo D:/foo
file://C:/foo C:/foo C:/foo C:/foo
file://D:/foo C:/foo D:/foo D:/foo
file:////foo/bar //foo/bar //foo/bar //foo/bar
//foo/bar //foo/bar //foo/bar //foo/bar
\\foo\bar //foo/bar //foo/bar \\foo\bar
For more information about file:// URL handling, see:
http://www-archive.mozilla.org/quality/networking/testing/filetests.html
Related issues:
- issue1153: File URIs aren't handled correctly in windows
This patch should preserve the fix implemented in
5c92d05b064e. However, it goes a step further and "promotes"
Windows-style drive letters from being interpreted as host names to
being part of the path.
- issue2154: Cannot escape '#' in Mercurial URLs (#1172 in THG)
The fragment is still interpreted as a revision or a branch, even in
paths to bundles. However, when file: is used, percent-encoded
entities are decoded, so file:test%23bundle.hg can refer to
test#bundle.hg ond isk.
Immediately sends local's heads to the server to check whether the server knows them all.
If it does, we can call getbundle immediately.
Interesting test output changes are:
- added 1 changesets with 0 changes to 1 files (+1 heads)
+ added 1 changesets with 0 changes to 0 files (+1 heads)
-> The new getbundle() actually fixes a bug vs. changegroupsubset() in that it no longer
returns unnecessary files when file revs are reused.
warning: repository is unrelated
+ requesting all changes
-> The new use of common instead of bases correctly indicates that an unrelated pull
gets all changes from the server.
This is a simple patch to make hg push/hg outgoing print their remote target
path even if the operation fails. I'm not sure if the original behavior was by
design.
This patch also changes one test to reflect the changed behaviour.
Known fingerprints of HTTPS servers can now be configured in the
hostfingerprints section. That makes it possible to verify the identify of web
servers without configuring and trusting the CA chain.
Limitations:
* Portnumbers are ignored, just like with ordinary certificates.
* Host name matching is case sensitive.
Previously, branch names were ideally manipulated as UTF-8 strings,
because they were stored as UTF-8 in the dirstate and the changelog
and could not be safely converted to the local encoding and back.
However, only about 80% of branch name code was actually using the
right encoding conventions. This patch uses the localstr addition to
allow working on branch names as local strings, which simplifies
handling so that the previously incorrect code becomes correct.
Without specifying the parent revision of the working copy, users will
update to tip, which is most likely the other head they were trying to
merge, not the revision they were at before the merge.
This is a revert of f6aa66376f81. The "bug" mentioned in this changeset is unclear:
hopefully using a test to cover this usage should prevent any bugs.
Since d6ca622d1122 the branch argument for addbranchrevs should be a tuple:
(hashbranch, branches)
The right empty value therefore is (None, []) instead of None.
Previously #foo and --branch foo were handled identically.
The behavior of #foo hasn't changed, but --branch now works like this:
1) If branchmap is not supported on the remote, the operation fails.
2) If branch is '.', substitute with branch of the working dir parent.
3) If branch exists remotely, its heads are expanded.
4) Otherwise, the operation fails.
Tests have been added for the new cases.
When trying to do hardlink-cloning, the os_link() call of the
first file tried already fails on Windows, if the source is on a
UNC path.
This change avoids calling os_link() for the rest of files, leaving
us with a *single* failed os_link() call per clone operation, if the
source can't do hardlinks.
When trying to do hardlink-cloning, the os_link() call of the
first file tried already fails on Windows, if the source is on a
UNC path.
This change avoids calling os_link() for the rest of files, leaving
us with a *single* failed os_link() call per clone operation, if the
source can't do hardlinks.
This avoids problem with unexpanded paths when it's not possible to
expand it at higher level (for example, if file:~/path/ is supplied as
path in schemes).
Previously, the name part of an repo#name url was interpreted as a
revision, similar to using the --rev option. Now it is instead looked
up as a branch first, and if that succeeds all the heads of the branch
will be processed instead of just its tip-most head. If the branch
lookup fails, it will be assumed to be an revision as before (e.g. for
tags).
Combining translated string fragments into bigger strings is bad
practice because it removes context from the fragments. The translator
sees the fragments in isolation and might not jump back to the source
to see how a string like "%d files %s" is actually used.
When cloning with the -r option or # url format from a tag the destination
repo most likely won't have the tag. We can save the lookup result to get to
the correct parent anyway. Similar to issue1306, but for tags.
In many places hg.parseurl is called with a url and "opts.get('rev')",
suggesting the second, optional argument can be None. Because opts['rev']
usually defaults to [] this never happens in practice.
However, extensions don't necessarily behave the same, but do copy this
pattern.
Also, include wider hg.parseurl tests, beyond a demonstration of the problem.
If the user created the clone target directory before running
the clone command, only cleanup the .hg/ repository when errors
occur. Leave the empty target directory in place.
With this change, "hg clone" looks like this:
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
So the user sees
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
while Mercurial is writing to disk to populate the working directory
With this change, "hg clone" looks like this:
% hg clone big big-work
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
A new function (extensions.extensions) allows the code that is
interested in those attributes to handle them directly.
This allows some cleanups of extensions.py. Notably, we can
remove the extensions.commandtable hack.
It also makes it easier to add standard extension attributes,
like a "hgwebsetup" function or a "helptable" dict that augments
the data in help.py, etc.
This allows you to do:
hg clone http://server/repo#stable
which is equivalent to:
hg clone -r stable http://server/repo
Future incoming, outgoing, and push commands will default to using
this id because it's recorded in the default path.
Other commands that accept URLs (push, pull, bundle, incoming, and
outgoing) also accept this syntax.
The ui object we received in this function may belong to another repo,
which could be confusing from the hook point of view. Trying to use
the ui object from the newly created repo should avoid this confusion.
