This patch makes "lock.lock.__init__()" take both vfs and lock file
path relative to vfs, instead of absolute path to lock file.
This allows lock file to be accessed via vfs.
This patch rewrites "copystore()" with vfs, because succeeding patch
requires "lock.lock()" invocation with vfs.
This patch uses 'dstbase + "/lock"' instead of "join()" with both
elements even on Windows environment but it should be reasonable,
because target files given from "store.copyfiles()" already uses "/"
as path separator.
"util.copyfiles()" between two vfs-s may have to be rewritten in the
future.
Before this patch, "extensions.extensions()" always lists up all
loaded extensions. So, commands handling multiple repositories at a
time like below enable extensions unexpectedly.
- clone from or push to localhost: extensions enabled only in the
source are enabled also in the destination
- pull from localhost: extensions enabled only in the destination
are enabled also in the source
- recursive execution in subrepo tree: extensions enabled only in
the parent or some of siblings in the tree are enabled also in
others
In addition to it, extensions disabled locally may be enabled
unexpectedly.
This patch checks whether each of extensions should be listed up or
not, if "ui" is specified to "extensions.extensions()", and invokes
"reposetup()" of each extensions only for repositories enabling it.
unionrepo is just like bundlerepo without bundles.
The implementation is very similar to bundlerepo, but I don't see any obvious
way to generalize it.
Some most obvious use cases for this would be log and diff across local repos,
as a kind of preview of pulls, for instance:
$ hg -R union:repo1+repo2 heads
$ hg -R union:repo1+repo2 log -r REPO1REV -r REPO2REV
$ hg -R union:repo1+repo2 log -r '::REPO1REV-::REPO2REV'
$ hg -R union:repo1+repo2 log -r 'ancestor(REPO1REV,REPO2REV)'
$ hg -R union:repo1+repo2 diff -r REPO1REV -r REPO2REV
This is going to be used in RhodeCode, and Bitbucket already uses something
similar. Having a core implementation would be beneficial.
79f69be29aed introduced a crash when cloning a url without path - where
util.url().path would be None.
This None will now be handled as ''. clone will thus abort with 'repository /
not found' as before.
Locating the share source when no default path is available is now handled in
subrepo._abssource(), so unconditionally setting a default path (and the
associated problems) can be avoided.
The test change reflects the fact that a default path is no longer set on the
resulting share.
We noa pass an unfiltered repo in the same way `localrepo.push` does. This does
not alter outgoing behavior and prevents possible crash with computing
common/missing.
The `findcommonincoming` code could be simplified to make this unnecessary, but
this is too much change for the freeze.
Now that changelog filtering is in place, it's become evident that
naming the filters according to the set of revs _not_ included in the
filtered changelog is confusing. This is especially evident in the
collaborative branch cache scheme.
This changes the names of the filters to reflect the revs that _are_
included:
hidden -> visible
unserved -> served
mutable -> immutable
impactable -> base
repoview.filteredrevs is renamed to filterrevs, so that callers read a
bit more sensibly, e.g.:
filterrevs('visible') # filter revs according to what's visible
We ensure all repositores created through `mercurial.hg.repository`
are "hidden" filtered. This is an even stronger enforcement than
86530c899687.
Citing Matt's response to changeset 86530c899687 installing filtering
in dispatch:
> Unfortunately, this means that code that doesn't go through dispatch (ie all
> those crazy misguided people using Mercurial as a library) are going to see
> these hidden changesets.
>
> Might be better to instead install the filter in localrepo construction by
> default and disable it in dispatch.
Bookmarks persistence still showed a fair amount of its legacy as a
monkeypatching extension. This encapsulates all bookmarks
serialization and parsing in a single class, and offers a single
location where other bookmarks storage engines can be substituted
in. As a result, many files no longer import the bookmarks module,
which strikes me as an encapsulation win.
This doesn't do anything to the current bookmark state yet, but I'm
hoping put that in the bmstore class as well.
Files in a subrepo were overwritten on update. But this should only happen on a
clean update (example: -C is specified).
Use the overwrite parameter introduced for svn subrepos in e3640daa4703 to
decide whether to merge changes (as update) or remove them (as clean).
The new function hg.updaterepo is intruduced to keep all update calls in hg.
test-subrepo.t is extended to test if an untracked file is overwritten
(issue3276). (Update -C is already tested in many places.)
The first two chunks are debugging output which has changed. (Because overwrite
is not always true anymore for subrepos)
All other tests still pass without any change.
ui contains repo specific configuration, so do not use it when there is a repo.
But pass it to hg.peer when there is no repo. Then it only contains global
configuration.
Do not pass ui because it contains the configuration of the repo. It is the
same object as repo.ui.
When a repo is passed to hg.peer, the global configuration is read from
repo.baseui.
The message "updating bookmark @ failed!" in test-bookmarks-pushpull.t
is correct, because the changeset that the @ bookmark points to is not
pushed to the target repository.
Before this change a bookmark named "default" or a branch named "@" would
cause the wrong changeset to be checked out.
The change in output of test-hardlinks.t is due to the fact that no unneeded
tag lookups for the tags "@" or "default" happen, therefore the cache file is
not created.
Recomputing branch cache on clone may be expensive,
therefore if possible we fetch it along with the data.
- If the clone is performed by copying, we just copy branchcache file.
- If we localrepo.clone and streaming then we follow the procedure:
1. Fetch branchmap from the remote
2. Fetch the actual data.
3. Find the latest rev within branch heads (tip at the time of
branchmap fetch)
4. Update the cache for the revs in [remotetip+1, tip]
This way we ensure that the branchcache is correct even in case
of races with commits.
We can only use copy clone if the cloned repo do not have any secret changeset.
The current method for that is to run the "secret()" revset on the remote repo.
But with proper filtering of hidden or unserved revision by the remote this
revset won't return any revision even if some exist remotely. This changeset
adds an explicit function to know if a repo have any secret revision or not.
The other option would be to disable filtering for the query but I prefer the
approach above, lighter both regarding code and performance.
Before this change, push would incorrectly fast-path the bundle
generation when extinct changesets are involved, because they are not
added to outgoing.excluded. The reason to do so are related to
outgoing.excluded being assumed to contain only secret changesets by
scmutil.nochangesfound(), when displaying warnings like:
changes found (ignored 9 secret changesets)
Still, outgoing.excluded seems like a good API to report the extinct
changesets instead of dedicated code and nothing in the docstring
indicates it to be bound to secret changesets. This patch adds extinct
changesets to outgoing.excluded and fixes scmutil.nochangesfound() to
filter the excluded node list.
Original version and test by Pierre-Yves.David@ens-lyon.org
There may be a more generic way that would add revset support to more commands
by adding revset support to addbranchrevs(), but given the proximity of the next
code freeze, a minimal change seems like the better choice.
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.
This introduces a peer method into all repository classes, which currently
simply returns self. It also changes hg.repository so it now raises an
exception if the supplied paths does not resolve to a localrepo or descendant.
Finally, all call sites are changed to use the peer and local methods as
appropriate, where peer is used whenever the code is dealing with a remote
repository (even if it's on local disk).
As a part of migration to vfs, this patch uses "self.root", which can
be recognized as the path relative to "self.vfs", instead of "path"
argument.
This fix allows to make invocations of "util.makedirs()" and
"os.path.exists()" while ensuring repository directory in
"localrepository.__init__()" ones indirectly via vfs.
But this fix also raises issue 2528: "hg clone" with empty destination.
"path" argument is empty in many cases, so this issue can't be fixed
in the view of "localrepository.__init__()".
Before this patch, it is fixed by empty-ness check ("not name") of
exception handler in "util.makedirs()".
try:
os.mkdir(name)
except OSError, err:
if err.errno == errno.EEXIST:
return
if err.errno != errno.ENOENT or not name:
raise
This requires "localrepository.__init__()" to invoke "util.makedirs()"
with "path" instead of "self.root", because empty "path" is treated as
"current directory" and "self.root" becomes valid path.
But "hg clone" with empty destination can be detected also in
"hg.clone()" before "localrepository.__init__()" invocation, so this
patch re-fixes issue2528 by checking it in "hg.clone()".
Verify uses repo.cancopy() to detect whether a repo is a plain old
local repo, so it was giving a confusing error message when secret
changesets were present.
Bookmarks are repository data, not working directory data. Only the current
bookmark is working directory data.
Some lock shuffling is required to avoid lockout between the initial mock lock
and locking of the localrepo instance that is created after copying.
