Use the existing method cmdutil.bailifchanged() instead of
implementing it again in fetch.py. An effect of this is that the error
messages in case of uncommited changes will be different.
Bid merge is now the default and it is not necessary to tell the user that an
experimental feature kicked in.
(It could however still be relevant to get a notice that it is one of the rare
criss-cross merge situations so the user is warned that the situation is more
tricky than usual.)
In most cases merges will work exactly as before.
The only difference is in criss-cross merge situations where there is multiple
ancestors. Instead of picking an more or less arbitrary ancestor, it will
consider both ancestors and pick the best bids.
Bid merge can be disabled with --config merge.preferancestor='!'.
Doing manual iteration is expensible. We rely on built in list iteration
whenever possible. The other case has to become a closure we cannot have a both
yield and return in the same function.
Previously there was no way of telling how much children or bookmarks or tags a
certain changeset has in a template. It was possible to tell if a changeset has
either 0 or not 0 bookmarks, but not to tell if it has 1 or 2 of them, for
example.
This filter, simply named count, makes it possible to count the number of items
in a list or the length of a string (or, anything that python's len can count).
E.g.: {children|count}, {bookmarks|count}, {file_adds|count}.
Testing the filter on node hash and shortened node hash is chosen because they
both have defined length.
As for lists of strings - children, tags and file_adds are used, because they
provide some variety and also prove that what's counted is the number of string
items in the list, and not the list stringified (they are lists of non-empty,
multi-character strings).
Additionally, revset template function is used for testing the filter, since
the combination is very flexible and will possibly be used together a lot.
(The previous version of this patch had an incorrect email subject and was
apparently lost - patchwork says the patch has been accepted, but it's not so.
The changes between that and this patch are minimal: now the filter does not
disturb the alphabetical order of function definitions and dict keys.)
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 allow a vfs argument to `addfilegenerator`. This allows generating files outside
of the store directory like bookmarks. However, this is not really working since
we do not have the infrastructure to backup and restore files outside of store.
By chance, the bookmark file is already backed up by another mechanism so we can
restrict this new feature to bookmarks (which is our only interest here) and
proceed.
The backup restoration is actually hard-coded for the main file. And this
hard-coded list is the only one used when repairing an interrupted transaction
from another process.
Solving this problem is out of the scope of this series so we document it and
work around its implications.
The final writing of the empty part was done explicitly. We now using proper
pack call using symbolic constant. This open simple change in the bundle2
format.
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.
Retrieving bookmarks before obsmarkers will avoid turning some changesets hidden
right before making them visible again if a bookmark keeps them visible.
The discovery phases for bookmarks now use the list of explicitly pushed bookmarks
to do addition, removal and overwriting.
Tests are impacted because this reduces the amount of listkeys calls issued, removes
some duplicated messages and improves the accuracy of some messages.
To gather all the bookmark pushing actions together, we need code performing
those actions to be ready for them. We need to be able to produce different
messages for different actions.
We need to explicitly push all local bookmarks when doing the clone from a local
repo to a remote one through ssh. This will let us remove the manual export of
bookmarks in clone and rely on the official exchange in push and pull instead.
Now that the standard pull function includes bookmarks, we need to ensure that
a copy clone also copies the bookmarks. This will let us drop the manual bookmark
pulling done independently during a clone.
There is no reason for bookmarks to get a special treatment. As a first step we
move the code as is in the `exchange.pull` function. Integration with the rest
of the flow will come later.
Adding bookmarks to pull means that most clone paths are now pulling bookmarks
through pull. We ensure that bookmark-update messages are properly suppressed in
that case.
In test-pull-http.t the 'requesting all changes' message disappear because we
now get the authentication error on the `listkeys`command before such message
is printed.
We'll add bookmark-related arguments to `repo.pull` so we need to widen the
signature of `repo.pull`. We should probably kill `repo.pull` now that
`repo.push` is dead but this is outside the scope of this series.
The search was introduced in 73b7669a499c without a convincing explanation why
it should be necessary ... except for consistency with templater handling.
Now, just keep it simple.
The search was introduced in 501e9ec9a85d. It might have been necessary back
then when using __file__ directly and frozen-ness wasn't considered. Now we
should know exactly where the templates can be found.
templates, help and locale data is normally stored as sub folders in the
directory containing the source of the mercurial module. In a frozen build they
live as sub folders next to 'hg.exe' and 'library.zip'.
These different kind of data were handled in different ways. Unify that by
introducing util.datapath. The value is computed from the environment and is
always used, so we just calculate the value on module load.
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
