The static http repository was doing his own filtering of capability ignoring
the filtering done in the local repo main class. This led to static http using
the current draft of bundle2. We now apply both.
Before this patch, all localrepositories support same features,
because supported features are managed by the class variable
"supported" of "localrepository".
For example, "largefiles" feature provided by largefiles extension is
recognized as supported, by adding the feature name to "supported" of
"localrepository".
So, commands handling multiple repositories at a time like below
misunderstand that such features are supported also in repositories
not enabling corresponded extensions:
- clone/pull from or push to localhost
- recursive execution in subrepo tree
"reposetup()" can't be used to fix this problem, because it is invoked
after checking whether supported features satisfy ones required in the
target repository.
So, this patch adds the set object named as "featuresetupfuncs" to
"localrepository" to manage hook functions to setup supported features
of each repositories.
If any functions are added to "featuresetupfuncs", they are invoked,
and information about supported features is managed in each
repositories individually.
This patch also adds checking below:
- pull from localhost: whether features supported in the local(= dst)
repository satisfies ones required in the remote(= src)
- push to localhost: whether features supported in the remote(= dst)
repository satisfies ones required in the local(= src)
Managing supported features by the class variable means that there is
no difference of supported features between each instances of
"localrepository" in the same Python process, so such checking is not
needed before this patch.
Even with this patch, if intermediate bundlefile is used as pulling
source, pulling indirectly from the remote repository, which requires
features more than ones supported in the local, can't be prevented,
because bundlefile has no information about "required features" in it.
The `_branchcache` attribute is turned into a dictionary. Key are filter name and
value is a `branchcache` object. Unfiltered version is cached as `None` filter.
The attribute is renamed to `_branchcaches` to avoid confusion with the previous
one. Both old and new contents are dictionary even if their contents are
different. I prefer possible extension code to crash right away instead of just
messing the wrong dictionary.
As all different caches work isolated to each other, this code keeps the
previous behavior of using the unfiltered cache we nothing is filtered. This
is a cheap way to have cache collaborate and nullify potential impact in the
default case.
This patch defines "join()" in each classes derived from "abstractvfs"
except "vfs", which already defines it.
This allows all vfs instances to be used for indirect file API
invocation.
For backwards compatibility, aliases for the old names are added,
except for "abstractopener", "statichttpopener" and "_fncacheopener",
because these are not used in Mercurial core implementation after this
patch.
"_fncacheopener" was only referred in "fncachestore" constructor, so
this patch also renames from "_fncacheopener" to "_fncachevfs" there.
This change separates peer implementations from the repository implementation.
localpeer currently is a simple pass-through to localrepository, except for
legacy calls, which have already been removed from localpeer. This ensures that
the local client code only uses the most modern peer API when talking to local
repos.
Peers have a .local() method which returns either None or the underlying
localrepository (or descendant thereof). Repos have a .peer() method to return
a freshly constructed localpeer. The latter is used by hg.peer(), and also to
allow folks to pass either a peer or a repo to some generic helper methods.
We might want to get rid of .peer() eventually.
The only user of locallegacypeer is debugdiscovery, which uses it to pose as a
pre-setdiscovery client. But we decided to leave the old API defined in
locallegacypeer for clarity and maybe for other uses in the future.
It might be nice to actually define the peer API directly in peer.py as stub
methods. One problem there is, however, that localpeer implements
lock/addchangegroup, whereas the true remote peers implement unbundle.
It might be desireable to get rid of this distinction eventually.
As a part of migration to vfs, this patch adds "vfs" fields to
"localrepository" class.
This allows new codes to access current "opener" objects related to
repositories via "vfs" fields, so patches referring to "vfs" will
replace referring to "opener" in time.
This patch also adds initializations for "vfs" fields to
"statichttprepository" class derived from it, because its constructor
doesn't invoke the constructor of "localrepository", so "vfs" fields
should be initialized explicitly as same as "opener" fields: it has no
working directory, so "wvfs" field is not added.
When requesting files using statichttprepo.httprangereader, a request for the
entire file is sent with a Range: bytes=0- header. This causes problems with
web servers such as Cherokee that return an HTTP 416 when an empty file is
requested in this way, which in turn cause some repository clone attempts to
fail. This patch omits the Range header when the entire file is being
requested, which fixes the problem.
When assigning a new object to filecached properties, the cached object that
was kept in the _filecache map was still holding the old object.
By implementing __set__, we track these changes too and update the cached
copy as well.
This commit add a whennodata list where extension can register a callback to be
called if no phase related data are found in the repository.
The goal is to ensure the existing extension that move phase data in 2.1 can
compute consistent phase boundary for existing repo.
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)
Like the previous patch to getauthinfo(), this also makes
username/password parsing more forgiving for SSH URLs.
This also opens up the possibility of allowing non-numeric ports,
since the URL parser has no problem handling them.
Related issues:
- issue851: @ in password in http url
- issue2055: nonnumeric port bug with https protocol
This improves the misleading error message
$ hg identify
abort: there is no Mercurial repository here (.hg not found)!
to the more explicit
$ hg identify
abort: requirement 'fake' not supported!
for all commands in commands.optionalrepo, which includes the identify
and serve commands in particular.
This is for the case when a new entry in .hg/requires will be defined
in a future Mercurial release.
We can stop pretending that we have to support anything else
than '/' for concatenating path elements anywhere.
Windows deals just fine with '/' in file paths and we already
have plenty of places which produce paths containing '/'
anyway when running on Windows.
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
* httprangereader: name, __iter__ and close are needed to mimic file object
* static-http opener:
- disallow write/append modes
- add (unused) atomictemp parameter
* static-http repo:
- root attribute is needed for localrepo.dirstate()
- _branch* attributes are required for commitctx and branchmap calls
* tags: force repo.opener.__iter__ call earlier to force httprangereader
to try to read the cache early, to avoid raising IOError later.
- self.tagscache to self._tags
- self._tagstypecache to self._tagtypes
- this is for consistency, readability, privacy, and to subtly hint
that "caching" is something else
- If remote does not support Range header, 200 is answered instead of 206. The
HTTPRangeHandler left these responses unchanged, so the data has to be sliced
by the receiver.
- httprangereader file pointer was not updated.
- unify httprangereader.py and statichttprepo.py:rangegreader()
- build the opener from url.py, that allows use to puse username and password
in the url, to follow the proxy settings from hgrc, etc.
Changeset 055df4ac4b13 which fixed issue965 (hg clone static-http
does not work for empty repos) broke cloning of repos with old layout
(without store) via static-http.
This fix makes cloning from old-style repositories possible again,
but will not allow cloning of empty old-style repositories as this
can not be detected reliably.
