revert: small refactoring in the way backup value are handled

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.

--HG--
extra : rebase_source : c0cb4472bba13829c23a8198e27508a11ef94f1f
revert: distinguish between "check" and "backup" strategy

"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.

--HG--
extra : rebase_source : dd335c4f18d6550be3670a32033499a2fe080c7d
revert: track added files with local modifications

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.

--HG--
extra : rebase_source : f5e00faea7e2e2104665f1f089d66e59937068bb
revert: properly back up added files with local modification

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.

--HG--
extra : rebase_source : a3ca18a707ad99510c2adacec2bc5fdee4dd7ce9
obsolete: gather all contents related to format version 0 in a single 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.

--HG--
extra : rebase_source : 6fc684157441ce2163f7c169b54e8c8191db03aa
obsolete: use the `version` argument in encodemarkers

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.

--HG--
extra : rebase_source : 4a3ecf03878f4b729d8997f370e62e7429b320e8
obsolete: use version constants in the format mapping

--HG--
extra : rebase_source : 49c358c8af75deab8f0d258139f7ec8adedbc1f0
push: rename `pushop.ret` to `pushop.cgresult`

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.

--HG--
extra : rebase_source : ce7bbb0703bafeb303c47eb578fc2ffc3a07d6df
push: `exchange.push` now returns the `pushoperation` object

Returning the pushop object gives access to more information (upcoming bookmark
push result for example). `localrepo.push` currently extracts the `cgresult` for
callers.

--HG--
extra : rebase_source : cebb99c1ddaab75349d5e2e7a62a12c8d7e39d7c
push: use `exchange.push` in `commands.push`

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.

--HG--
extra : rebase_source : f3361889019ca8ac118336fabf2e2a0b2962e030
clone: use `exchange.push` instead of `localrepo.push`

The latter is going away.

--HG--
extra : rebase_source : 5ebc4505e4e34c3445f27691c5dc8555bf79ee07
push: `exchange.push` instead of `localrepo.push`

The latter is going away.

--HG--
extra : rebase_source : 3dbc54e4dcc3b1908438dc0b1754eb78cb53fdce
locarepo: remove the `push` method (API)

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.

--HG--
extra : rebase_source : 1b80397906b53171d3c7307c6ab3686d4bc1b56d
push: sanitize handling of bookmark push return value

Mixing return and assignment does not make sense, let's unify this.
exchange: import bookmarks as bookmod

Using the original names makes it difficult to use `bookmarks` as a variable
name.

--HG--
extra : rebase_source : 725a6de1c330cfe44ecde567f76ca9fd31c1bc40
push: pass list of bookmark to `exchange.push`

Currently stored but not unused. This parameter will control bookmarks explicitly
pushed (added to the server if missing).
push: add `pushoperation.bkresult`

This attribute will be used to carry the result of the bookmark push (when the
`push` function will effectively be doing any bookmarks pushes)
push: perform bookmark export in the push function

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.
pull: gather all bookmark-pulling code together

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.
bookmark: make the search for divergent names more robust

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