If push failed we should not expect the pushed changeset to exist on remote.
The common set before the push is used for phase related operation instead of
common + missing.
Note:
* We still pull phase data even if push fails
* We still try to push data even if push fails (same than bookmark)
The ``discovery.prepush`` function was doing multiple things not related to
discovery. This changeset move some code into the ``localrepo.push`` method. The
old ``discovery.prepush`` function jobs is now restricted to checking for
multple head creation. It was then renamed ``discovery.checkheads``.
This new ``discovery.checkheads`` function may receive several other changes in
the future but we are a bit too much near the freeze for a wider refactoring.
New tags were written to .hgtags / .hglocaltags without updating or
invalidating the localrepo cache.
Before 462e6cfb1bac a lock was acquired soon after the new tags had been
written, and that invalidated the cache so the new tags for example could be
seen in pretxncommit hooks. With 462e6cfb1bac the lock had already been
acquired at this point and the missing cache invalidation was exposed.
The tag caches will now explicitly and immediately be invalidated when new tags
are added.
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.
As mq automatically sets changesets as secret, it should make them draft when he
is done with it. We do not move them automatically to draft when we detect that
something else have also set them as secret through their parents.
This is introduce to allow temporary overwriting of a config value while being
able to reinstall the old value once done. The main advantage over using
``config`` and ``setconfig`` is that backup and restore will properly restore
the lack of any config. Restoring the fact that there was no value is important
to allow config user to keep using meaniful default value.
A more naive approach will result in the following scenario::
Before:
config(section, item, my_default) --> my_default
temporal overwrite
old = config(section, item)
…
setconfig(section, item, old)
After
config(section, item, my_default) --> None
The first user of this feature should be mq to overwriting minimal phase of
future commit.
When the user pulls from a remote repository that is not his default repo, it
is quite likely that he will pull a new head. This means that if he tries to
merge or rebase with the other head, he will run into a problem becuase
largefiles has no way of tracking where the remote repository for this other
head is, so it cannot download the largefiles from this other remote repository.
It will attempt to download them from its default remote repository, which will
not yet contain the largefiles.
This patch solves this problem by caching any new largefiles for all heads
directly into the system cache at the time of the pull, so they are available
later.
This behavior is actually more in line with Mercurial's distributed nature,
because pulling already implies we have a connection to the remote server, but
merging or rebasing does not.
When support for handling explicit paths in subrepos was added to the forget
command (155b89136ae7), subrepo recursion wasn't taken into account. This
change fixes that by pulling the majority of the logic of commands.forget into
cmdutil.forget, which can then be called from both there and subrepo.forget.
When support for handling explicit paths in subrepos was added to the add
command (825c4cefde4b), subrepo recursion wasn't taken into account. This
change adds an explicitonly argument to cmdutil.add to allow controlling which
levels of recursion should include only explicit paths versus all matched
paths.
When support for handling add/forget of explicit paths within subrepos was
added (825c4cefde4b/155b89136ae7), nested subrepos weren't handled properly.
This change adds test coverage to expose the broken behavior, which will be
fixed in later patches.
Rebase will remove empty changesets and will also completely remove the mq
patch file for rebased empty patches.
Starting with f64ab644b39f (1.9) it would preserve guards by writing the old
series file back. That would however also reintroduce removed patch files in
the series file and the inconsistency would make qpop + qpush fail.
This patch backs out most of f64ab644b39f and makes sure guards are preserved
without reintroducing removed patches.
The large or-expressions we used to build required a substantial
amount of subset filtering in orset() which was inefficient. Instead we build a
single string which we process in one go with a special internal predicate.
Inadvertently support is currently only for https. For some reason I
thought xmlrpclib.SafeTransport did http and https, but it is https only.
So create http and https XMLRPC transports that retain cookies. Decide which
to use by inspecting the Bugzilla URL.
If file data starts with '\1\n', it will be escaped in the revlog to
create an empty metadata block, thus adding four bytes to the size in
the revlog size index. There's no way to detect that this has happened
in filelog.size() faster than decompressing each revision [1].
For filectx.cmp(), we have the size of the file in the working directory
available. If it differs by exactly four bytes, it may be this case, so
do a full comparison.
[1]: http://markmail.org/message/5akdbmmqx7vq2fsg
As of 1ffaca626da1 (first released as part of Mercurial 2.0), the rebase command
accepted ONLY revsets for the source and base arguments and no longer accepted
old-style revision specifications. As a result, some revision names were no
longer recognised, e.g.
hg rebase --base br-anch
abort: unknown revision 'br'!
These arguments are now interpreted first as old-style revision specifications,
then as revsets when no matching revision is found. This restores backwards
compatibility with releases prior to 2.0.
This patch makes "hg remove" work the same way on largefiles as it does on
regular Mercurial files. If you try to remove an added largefile, the removal
fails and you are instead prompted to use "hg forget" to undo the add.
