bookmark: complexity pull-push test to have deeper tree

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.

--HG--
branch : stable
bookmark: prevent crashing when a successor is unknown locally (issue3680)

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.

--HG--
branch : stable
bookmark: simplify nodemap check introduced in the previous changeset

--HG--
branch : stable
clone: make sure to use "@" as bookmark and "default" as branch (issue3677)

Before this change a bookmark named "default" or a branch named "@" would
cause the wrong changeset to be checked out.

The change in output of test-hardlinks.t is due to the fact that no unneeded
tag lookups for the tags "@" or "default" happen, therefore the cache file is
not created.

--HG--
branch : stable
test-bookmarks.t: check that bookmark "default" is not automatically checked out

This verifies that c9339efed653 fixes the problem originally reported in
issue3677.

--HG--
branch : stable
test-clone.t: check that branch "@" is not automatically checked out

This verifies that c9339efed653 fixes the second problem mentioned in
issue3677.

--HG--
branch : stable
clone: activate @ bookmark if updating to it

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.

--HG--
branch : stable
clone: print bookmark name when clone activates a bookmark

Similar to the message that prints the checked out branch name.
Without this, the user might accidentally move the @ bookmark.

--HG--
branch : stable
bookmarks: backed out new message from changeset 52c7e171e355

Not strictly a bugfix, hasn't achieved consensus yet.

--HG--
branch : stable
subrepo: isolate configuration between each repositories in subrepo tree

Before this patch, repository local configurations are not isolated
between repositories in subrepo tree, because "localrepository"
objects for each subrepositories are created with "ui" instance of the
parent of each ones.

So, local configuration of the parent or higher repositories are
visible also in children or lower ones.

This patch uses "baseui" instead of "ui" to create repository object:
the former contains only global configuration.

This patch also copies 'ui.commitsubrepos' configuration to commit
recursively in subrepo tree, because it may be set in not
"repo.baseui" but "repo.ui".

--HG--
branch : stable
extra : rebase_source : a831bfdbef21cb5c7c926e15408fcf7518aeb856
peer: subrepo isolation, pass repo instead of repo.ui to hg.peer

Do not pass ui because it contains the configuration of the repo. It is the
same object as repo.ui.
When a repo is passed to hg.peer, the global configuration is read from
repo.baseui.

--HG--
branch : stable
extra : rebase_source : ee40dab7fb1749f0a3739cb04e0202019ed5f379
subrepo: more isolation, only use ui for hg.peer when there is no repo

ui contains repo specific configuration, so do not use it when there is a repo.
But pass it to hg.peer when there is no repo. Then it only contains global
configuration.

--HG--
branch : stable
extra : rebase_source : 6dde6318775cd544bd17c49dd54a9c23dee893a3
subrepo: subrepo isolation, pass baseui when cloning a new subrepo (issue2904)

Create the repo with baseui because it should only get the global configuration.

After this patch issue2904 is finally fixed.

--HG--
branch : stable
extra : rebase_source : 46ae31aec18d70f32f53bdf07875216a69eddcc9
largefiles: respect the rev when reading standins in copytostore() (issue3630)

When the rev isn't specified, the standin for the working copy gets read.  But
convert doesn't update the working copy for each cset it processes, so there is
no standin and the 'hg convert' would abort complaining about the standin being
missing.

Note that if the largefile is not in the user cache, 'hg convert' complains
about the largefile itself missing from the destination repo.

--HG--
branch : stable
extra : rebase_source : 73454a8abf506b87a8457d31a0f75ffb2a8860f5
largefiles: don't copy largefiles from working dir to the store while converting

Previously, if one or more largefiles for a repo being converted were not in the
usercache, the convert would abort with a reference to the largefile being
missing (as opposed to the previous patch, where the standin was referenced as
missing).  This is because commitctx() tries to copy all largefiles to the
local store, first from the user cache, and if the file isn't found there, from
the working directory.  No files will exist in the working directory during a
convert, however.  It is not sufficient to force the source repo to be local
before proceeding, because clone and pull do not download largefiles by default.

This is slightly less than ideal because while the conversion will now complete,
it won't be possible to update to revs with missing largefiles unless the user
intervenes manually, because there is no default path pointing back to the
source repo.  Ideally these files would be cached during the conversion.

This check could have been done in reposetup.commitctx() instead, but this
ensures the local store directory is created, which is necessary to enable the
standin matcher.

The rm -> 'rm -f' change in the test is to temporarily suppress an error
clearing the cache- as noted, the cache is is not repopulated during convert.
When that is fixed, this can be changed back and the verification errors will
disappear too.

--HG--
branch : stable
extra : rebase_source : 9e876ebace969f62532d461049897adebb182bba
dirstate: handle dangling junctions on windows (issue2579)

--HG--
branch : stable
extra : rebase_source : 82b641283d22970fd33af1ec0607132822061f96