Consider a bookmark B that exists both locally and remotely. If B is updated
remotely, and then a pull is performed where the pull set contains the new
location of B, the bookmark is updated locally. However, if remote B is
updated in the middle of a pull to a location not in the pull set, the
bookmark won't be updated locally at all.
To fix this, list bookmarks before pulling in changesets, not after. This
still leaves a race open if B gets moved in between listing bookmarks and
pulling in changesets, but the race window is much smaller. Fixing the race
properly would require a bundle format upgrade.
test-hook.t's output changes because we no longer do two listkeys calls during
pull, just one.
test-pull-http.t's output changes because we now search for bookmarks before
searching for changes.
If the active bookmark doesn't point at a parent of the working dir
(e.g. a pull moved it out from under us), we nonetheless show it as
active. This follows on 13ea5e437ff8 in removing the dichotomy (at least
in the UI) between "current" and "active" bookmarks.
The test in question doesn't have anything to do with having an active
bookmark. This change makes the test change the two bookmarks it affects
without making them active. It clears the way for adding a test for
updating to an active bookmark that moved out from under us.
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.
The `%ln` revset substitution does not accept unknown node. We prune unknown
node from potential successors before computing descendants.
This have no impact on the result of this function.
- Descendants of unknown changeset as unknown,
- all successors of unknown changesets are already return by the call who
returned those same unknown changesets,
- unknown changesets are never a valid destination for a bookmark.
This changeset only touch test.
The previous test was correct, it tested that the successors of an old bookmark
position was seen as a valid destination for bookmark.
However, a newer version is made for two reason:
(1) The new test check further. It check that the descendant of the successors
is a valid destination
(2) An ever more complexe test is needed to validate a future fix to issue 3680
Splitting complexification of the test and actual bugfix help to reduce the
noise in the bugfix changeset. Issue 3680 is NOT fixed by this changeset.
This changeset treats the bookmark "@" as a special case for the naming of
divergent bookmarks, as per the tables below. For the <no alias> case, the
actual suffix will vary, depending on what suffixes are already in use.
Before:
Bookmark | Remote | Divergent Bookmark
--------------------------------------
foo | bar | foo@bar
foo | <no alias> | foo@1
@ | bar | @@bar
@ | <no alias> | @@1
After:
Bookmark | Remote | Divergent Bookmark
--------------------------------------
foo | bar | foo@bar
foo | <no alias> | foo@1
@ | bar | @bar
@ | <no alias> | @1
This case is likely to be more common now that c1644655c164 has made the "@"
bookmark have special meaning to clone.
The change in behavior was discussed on the mailing list in the thread below:
http://markmail.org/thread/rwedgxp7le5j2h2f
When we rewrite a bookmarked changeset, we want to update the
bookmark on its successors. But the successors are not descendants
of its precursor (by definition). This changeset alters the bookmarks
logic to update bookmark location if the newer location is a successor
of the old one[1].
note: valid destinations are in fact any kind of successors of any kind
of descendants (recursively.)
This changeset requires the enabling of the obsolete feature in
some bookmark tests.
A relevant obsolete marker may have been added -after- we previously
exchanged the changeset. We have to search for remote heads that
disappear by the sole fact of pushing obsolescence.
This case will also happen when remote got the new version from a
repository that does not propagate obsolescence markers.
The problem occured when pushing a changeset that at the same time creates a
new named branch head and moves a bookmark. The code invoked methods that only
exist on localrepo instances, so it failed for any other type of remote. The
test suite only tested against local remotes.
The kill call at the end is redundant, as we already have
199: $ hg serve -p $HGPORT -d --pid-file=../hg.pid -E errors.log
200: $ cat ../hg.pid >> $DAEMON_PIDS
So there is nothing left that would not already be killed by the $DAEMON_PIDS
mechanism.
Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
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.
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.
We want to update the current bookmark to the most recent revision on
current branch unless there is a remote bookmark that points to
a different descendant. Addchangegroup is called before we can check for
remote bookmarks.
We don't update the bookmark in addchangegroup anymore to allow proper updating
of bookmarks in pull.
