The current behaviour is to return the previous one in the series but at the
same time the implementation is buggy because it does not take guarded patches
in account.
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 1
This makes pull agree with the rest of the table and makes it easy to
detect "nothing was pulled" in scripts.
Marks phase data as dirty when computing default phase. Actual writing is done
when the lock is released. So, read only operation don't write phase data
because they don't lock the repo.
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 0
This fixes the lower-right entry.
The only purpose of 'diff -U0' was to show that 'hg diff -U0' did almost the same.
Unfortunately 'diff -U0' on Solaris gives incorrect line numbers. Masking it
with globs wouldn't it make sense, so removing it is the best solution.
When mq changeset are secret, they don't appear in outgoing and won't be
pushed. So it's not necessary to abort the push.
The checkpush call is protected by lock to prevent race on phase.
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.
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.
