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
Pulling bookmarks is done in two rounds. First we do a simple update, then we use
the content of the `bookmark` argument to possibly overwrite some bookmark
with their remote location.
The second step was not done right after the first one for some obscure reason.
We now perform them one after the other.
This part is responsible for adding new bookmarks on the remote. Before that,
it was done on its own in `commands.push`. The export is still not integrated
with the rest of the push process, but at least it now dwells in the right
function.
All the logic of this function is in the exchange.push function for some time.
We just stop calling `localrepo.push` in `command.push` to have access to more
information. Leaving `localrepo.push` in place will let third-party extensions
wrap it but it would never be called by `hg push` making the wrapping useless.
Therefore, the method is removed so that third-party code fail noisily and
get properly upgraded.
To gain access to all results from the push, we need to have access to the
`pushoperation` object. We call `exchange.push` to do so.
It is impossible to just change the `localrepo.push` signature because the
change may be too subtle to be caught by external extension wrapping
`localrepo.push`.
This mean we'll have to kill `localrepo.push` because just using
`exchange.push` in `commands.py` would silently disable all wrapping around
`localrepo.push` by third-party extensions. So we'll remove it in a later
changeset to get such extensions to fail noisily.
Returning the pushop object gives access to more information (upcoming bookmark
push result for example). `localrepo.push` currently extracts the `cgresult` for
callers.
We are about to introduce more results-related attributes on pushop (for
bookmarks) so we need a more distinctive name. We now use `cgresult` as
`pulloperation` does.
Recent scientific studies show that assigning a variable have no effect on
a unrelated constant. We therefore use the variable where we intended to in the
first place.
All contents includes documentation, constants, and functions, so we
gather all of those things into a single location. The diff is confusing
because it cannot understand what code is semantically moved around in this
grand migration.
These files were previously not backed up because the backup mechanism was not
smart enough. This leads to data lose for the user since uncommitted contents
were discarded.
We now properly move the modified version to <filename>.orig before deleting it.
We have to use a small hack to do a different action if "--no-backup" is
specified. This is needed because the backup process is actually a move (not a
copy) so the file is already missing when we backup. The internet kitten is a
bit disapointed about that, but such is life.
This patch concludes the "lets refactor revert" phases. We can now open the
"Lets find stupid bug with renames and merge" phases.
I'm sure that now that the code is clearer we could do it in another simpler
way, but I consider the current improvement good enough for now.
Those files need to be backed up but are currently not. We compute the set of
them to be able to use a different backup strategy in the next changeset.
"check" behaves as backup did before. We check if the current file differs
from destination and we create a backup if it does. This is used for untracked
files that will be overwritten by formerly-deleted files. We have to do the manual
check since no status output can provide the content comparison.
"backup" is now doing unconditional backup. This can be used for files seen as
modified compared to both the target and the working directory. In such a case, we
know that the file differs from target without actually comparing any content.
This new "backup" strategy will be especially useful in the case of files added
between the target and the working directory -parent- with additional modifications
in the working directory -itself-. In that case we know we need to back it up, but we
cannot run the content check as the files does not exists in target.
The current backup value may have two different values:
1. Do not try to do backup
2. Do backup if applicable
We are about to move to:
1. Do not try to do backup
2. Do backup if applicable
3. Do backup in all cases
So we change the current values to make room for the new one.
Since d0ec15e840e5, we were getting this strange message with Py2.4:
TypeError: argument 1 must be impossible<bad format char>, not int
..because we were using the 'n' type specifier introduced in 2.5.
It turns out that offset is actually a revision number index, which
ought to be an int anyway. So we store it in an int, use the 'i'
specifier, rely on Py_ParseTuple for range checking, and rename it to
avoid type confusion.
Since ce44c3c7c2be, we have a diff.nobinary option. This is handy, but
the only way I found out about it was by looking at the release notes
for 3.1, which is not something I normally do.
Since 266cfa7de44d, --template option is ignored if --style is specified,
which is wrong according to the doc of show_changeset():
Display format will be the first non-empty hit of:
1. option 'template'
2. option 'style'
...
