This only alter the third block executed when:
* repo have secret changeset
* onlyheads is not None
In other case findcommonoutgoing already had this behavior
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.
The prepush documentation claim that when we refuse to push, the second element
of the returng tuple is an "outgoing" integer. value should be 0 when no
outgoing changeset and 1 otherwise. In pratice if there are no outgoing
changeset, "outgoing" value is alway 1 and util.Abort is raised on other error.
the stable branch also include this error so it wasn't introduced by a recent
refactoring.
The outgoing object gains an "excluded" members holding all changesets which
were excluded because there where secret.
The core discovery code now remove secret changeset from discovery by default.
This means that any command relying on discovery will exclude secret changeset.
Most notable one are outgoing and bundle. (But bundle with and explicit
``--base`` still allow to bundle outgoing changeset.
Simplifies client logic in multiple places since it encapsulates the
computation of the common and, more importantly, the missing node lists.
This also allows an upcomping patch to communicate precomputed versions of
these lists to clients.
Any secret changesets will be excluded from pull and push. Phase data are
properly synchronized on pull and push if a changeset is seen as secret locally
but is non-secret remote side.
This patch does not handle the case of a changeset secret on remote but known
locally.
When talking to old server discovery use heads of the 'None' branch to refer to
topological heads. This use of None should never make it to the end user.
previously, this info was only shown with --debug
Note that the new remote heads are only shown if the command aborts,
that is, they are *not* shown if --force was specified.
See also change 914ebeb62db8.
and don't mention the branch if it's the default branch.
OLD:
$ hg push ../a
pushing to ../a
searching for changes
abort: push creates new remote heads on branch 'default'!
(you should pull and merge or use push -f to force)
NEW:
$ hg push ../a
pushing to ../a
searching for changes
abort: push creates new remote head 1e108cc5548c!
(you should pull and merge or use push -f to force)
This helps to identify which local head is causing troubles.
See also change 914ebeb62db8.
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.
Adds a new discovery method based on repeatedly sampling the still
undecided subset of the local node graph to determine the set of nodes
common to both the client and the server.
For small differences between client and server, it uses about the same
or slightly fewer roundtrips than the old tree-based discovery. For
larger differences, it typically reduces the number of roundtrips
drastically (from 150 to 4, for instance).
The old discovery code now lives in treediscovery.py, the new code is
in setdiscovery.py.
Still missing is a hook for extensions to contribute nodes to the
initial sample. For instance, Augie's remotebranches could contribute
the last known state of the server's heads.
Credits for the actual sampler and computing common heads instead of
bases go to Benoit Boissinot.
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.
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.
With this patch applied, Mercurial will list the hashes of new remote heads
if push --debug aborts because of new remote heads (option -f/--force not set).
Example:
$ hg push --debug repo1
using http://example.org/repo1
http auth: user johndoe, password not set
sending between command
pushing to http://example.org/repo1
sending capabilities command
capabilities: changegroupsubset stream=1 lookup pushkey unbundle=HG10GZ,HG10BZ,HG10UN branchmap
sending heads command
searching for changes
common changesets up to 187dd3f0a37d
sending branchmap command
new remote heads on branch 'default' <- new output line
new remote head 5862c07f53a2 <- new output line
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Compare to without --debug (not changed by this patch, including it here
for reference purposes only):
$ hg push repo1
pushing to http://example.org/repo1
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Motivation for this change:
'hg outgoing' may list a whole lot of benign changesets plus an odd changeset
that will trigger the "new remote heads" abort. It can be hard to spot that
single unwanted changeset (it may be an old forgotten experiment, lingering
in the local repo).
"hg log -r 'heads(outgoing())'" might be useful, but that also lists a head
that may be benign on push.
Inside prepush(), we already know which heads are causing troubles on 'hg push'.
Why not make that info available (at least on --debug)?
This would also be helpful for doing remote support, as the supporter can ask
the user to paste the output of 'hg push --debug' on error and then ask further
questions about the heads listed.
A Python set seems to do this already when you iterate over it, but
this should be considered an implementation detail and not something
we can rely on.
This also gets rid of an unnecessary string conversion -- the set
already contains strings.
