This change touches every module in which repository.opener was being used, and
changes it for the equivalent repository.vfs. This is meant to make it easier
to split the repository.vfs into several separate vfs.
It should now be possible to remove localrepo.opener.
bookmarks.compare() previously lumped identical bookmarks in the
"invalid" bucket. This patch adds a "same" bucket.
An 8-tuple for holding this state is pretty gnarly. The return value
should probably be converted into a class to increase readability. But
that is beyond the scope of a patch intended to be a late arrival to
stable.
Instead of manually writing bookmarks when they are updated, we can just record this
update to the transaction and rely on it to update the on-disk file.
If we want to handle bookmarks in a transaction we need to decouple the file
handling and the actual production of the content. This is similar to how we
handle phases in transaction.
We do all the things in one go now, updating existing bookmark, adding new ones,
and overwriting the ones explicitly specified for --bookmark. This impacts the
tests by removing some duplicated or unnecessary output.
We translate the "url we update from" and "the url in the config" into their
canonical representation. This is useful for urls that have multiple equivalent
forms:
/foo/bar/ == file:/foo/bar/ == file:///foo/bar
eg: hg pull --config path.bar=/foo/bar/ file:/foo/bar
Previously a bookmark pushkey would be rejected if the specified 'old' value
didn't match the servers 'current' value. This change allows this situation, as
long as the 'current' server value equals the 'new' pushkey value already.
We are trying to write a hook that forces a server bookmark to move forward,
using a changegroup hook. If the user also pushed the bookmark, they would get
an error, since they computed their pushkey (old,new) pair before the server
moved the bookmark. Long term, bundle2 will let us do this more smartly, but
this change seems reasonable for now.
Prior to this, doing "hg rebase -s @foo -d @" would delete @, which is
obviously wrong: a primary bookmark should never be automatically deleted.
This change blocks the deletion, but doesn't yet properly clean up the
divergence: @ should replace @foo.
The bookmark exchange code was already extracted during a previous cycle. This
changesets moves the extracted function in this module. This function will read
and write data in the `pushoperation` object and It is preferable to have all
core function collaborating through this object in the same place.
This changeset is pure code movement only. Code change for direct consumption of
the `pushoperation` object will come later.
Previously, when an obsolete changeset was bookmarked, successor changesets were not considered
when moving the bookmark forward. Now that a bare update will move to the tip most of the
successor changesets, we also update the bookmark logic to allow the bookmark to move with this
update.
Tests have been updated and keep issue4015 covered as well.
This patch adds "updateremote()", which uses "compare()" to compare
bookmarks between the local and the remote repositories, to replace
pushing local bookmarks in "localrepository.push()".
This patch adds "pushtoremote()", which uses "compare()" to compare
bookmarks between the local and the remote repositories, to replace
pushing local bookmarks in "commands.push()".
To update entries in bmstore "localmarks", this patch uses
"bin(changesetid)" instead of "repo[changesetid].node()" used in
original "updatefromremote()" implementation, because the former is
cheaper than the latter.
This makes `hg pull --update` behave the same wrt the active bookmark as
`hg pull && hg update` does as of 13ea5e437ff8. A helper function,
bookmarks.calculateupdate, is added to prevent code duplication between
postincoming and update.
This patch resolves divergent bookmarks between the current active bookmark
MARK and the new destination. This situation can arise when pulling new
changesets, abandoning your current changesets actively bookmarked with MARK
via strip, and then doing a bare update. The non-divergent but active bookmark
MARK is then moved to a common ancestor of the new changesets and the abandoned
changesets.
Test coverage is added.
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.
Don't expose unserved changesets to remote repos. Thanks to Sean Farley
<sean.michael.farley@gmail.com> for tracking down the issue and
Pierre-Yves David <pierre-yves.david@ens-lyon.org> for the fix.
If the current bookmark (the one listed in .hg/bookmarks.current)
doesn't point to a parent of the working directory, e.g. if it was moved
by a pull, use that as the update target instead of the tipmost
descendent.
A small predicate is (finally) added to the bookmarks module to check
whether the current bookmark is also active.
The logic recently added to `bookmark.validdest` uses data about obsolete
changesets to see if a bookmark destination is valid. Obsolete changesets
are likely to be filtered, so we need to work on an unfiltered repository.
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.
Update to this code was minimalist when `allsuccessors` argument were changed
from a list to a set. As this code is getting my attention again I realised we
can drastically simplify this part of the code by issue a single call to
`allsuccessors`.
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.
