repoview: fix 0L with pack/unpack for 2.4

--HG--
extra : rebase_source : 047bc6a05b8361edb5dbd3badc6d33ed88e12428
largefiles: omit restoring standins if working parent is not rollbacked

For efficiency, this patch omits restoring standins and updating
lfdirstate, if the parent of the working directory is not rollbacked.

This patch adds the test not to confirm whether restoring is skipped
or not, but to detect unexpected regression in the future: it is
difficult to distinguish between skipping and perfectly restoring.

--HG--
extra : rebase_source : 6dff57e032fd5b7ec7c9999e4277b8aee02082f9
largefiles: restore standins from non branch-tip parent at rollback correctly

Before this patch, "hg rollback" can't restore standins correclty, if:

  - old parent of the working directory is rollback-ed, and
  - new parent of the working directory is not branch-tip

"overriderollback" uses "merge.update" as a kind of "revert" utility
to restore only standins with "node=None", and this makes
"merge.update" choose "branch-tip" revision as the updating target
unexpectedly.

Then, "merge.update" restores standins from the branch-tip revision
regardless of the parent of the working directory after rollback and
this may cause unexpected behavior.

This patch invokes "merge.update" with "node='.'" to restore standins
from the parent revision of the working directory.

In fact, this "merge.update" invocation will be replaced in the
subsequent patch to fix another problem, but this change is usefull to
inform reason why such complicated case should be tested.

--HG--
extra : rebase_source : 4f325244af3cb9c7190c4f8d9a59d5624bca4e63
largefiles: restore standins according to restored dirstate

Before this patch, standins are restored from the NEW parent of the
working directory at "hg rollback", and this causes:

  - standins removed in the rollback-ed revision are restored, and
    become orphan, because they are already marked as "R" in the
    restored dirstate and expected to be unlinked

  - standins added in the rollback-ed revision are left as they were
    before rollback, because they are not included in the new parent
    (this may not be so serious)

This patch replaces the "merge.update" invocation with a specific
implementation to restore standins according to restored dirstate.

This is also the preparation to centralize the logic of updating
largefiles into the function wrapping "merge.update" in the subsequent
patch.

After that patch, "merge.update" will also update largefiles in the
working directory and be redundant for restoring standins only.

--HG--
extra : rebase_source : e045c78ea61b56f91b0534da1bf0e2fea9430b3c
largefiles: unlink standins not known to the restored dirstate at rollback

Before this patch, standinds not known to the restored dirstate at
rollback still exist after rollback of the parent of the working
directory, and they become orphans unexpectedly.

This patch unlinks standins not known to the restored dirstate.

This patch saves names of standins matched against not
"repo.dirstate[f] == 'a'" but "repo.dirstate[f] != 'r'" before
rollback, because branch merging marks files newly added to
dirstate as not "a" but "n".

Such standins will also become orphan after rollback, because they are
not known to the restored dirstate.
largefiles: move "updatestandin" invocation to "hg.updaterepo" wrapper

Code paths below expect "hg.updaterepo" (or "hg.update" using it) to
execute linear merging:

  - "update" in commands
  - "postincoming" in commands, used for:
    - "hg pull --update"
    - "hg unbundle --update"
  - "hgsubrepo.get" in subrepo

For linear merging with largefiles, standins should be updated
according to (possibly dirty) largefiles before "merge.update"
invocation to detect conflicts correctly.

Before this patch, only the "update" command can execute linear merging
correctly, because largefiles extension takes care of only it.

This patch moves "updatestandin" invocation from "overrideupdate" ("hg
update" wrapper) to "_hgupdaterepo" ("hg.updaterepo" wrapper) to
execute linear merging in "hg.updaterepo" correctly.

This is also a preparation to centralize the logic of updating
largefiles in the working directory into the function wrapping
"merge.update" in the subsequent patch.
largefiles: update largefiles even if rebase is aborted by conflict

Before this patch, largefiles in the working directory aren't updated
correctly, if rebase is aborted by conflict. This prevents users from
viewing appropriate largefiles while resolving conflicts.

While rebase, largefiles in the working directory are updated only at
successful committing in the special code path of
"lfilesrepo.commit()".

To update largefiles even if rebase is aborted by conflict, this patch
centralizes the logic of updating largefiles in the working directory
into the "mergeupdate" wrapping "merge.update".


This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, largefiles in the
working directory should be updated with other (normal) files
simultaneously while "merge.update" execution: maybe by hooking
"applyupdates".

"Action list based updating" introduced by hooking "applyupdates" will
also improve performance of updating, because it automatically
decreases target files to be checked.


Just after this patch, there are some improper things in "Case 0" code
path of "lfilesrepo.commit()":

  - "updatelfiles" invocation is redundant for rebase
  - detailed comment doesn't meet to rebase behavior

These will be resolved after the subsequent patch for transplant,
because this code path is shared with transplant.


Even though replacing "merge.update" in rebase extension by "hg.merge"
can also avoid this problem, this patch chooses centralizing the logic
into "mergeupdate", because:

  - "merge.update" invocation in rebase extension can't be directly
    replaced by "hg.merge", because:

    - rebase requires some extra arguments, which "hg.merge" doesn't
      take (e.g. "ancestor")

    - rebase doesn't require statistics information forcibly displayed
      in "hg.merge"

  - introducing "mergeupdate" can resolve also problem of some other
    code paths directly using "merge.update"

    largefiles in the working directory aren't updated regardless of
    the result of commands below, before this patch:

    - backout (for revisions other than the parent revision of the
      working directory without "--merge")

    - graft

    - histedit (for revisions other than the parent of the working
      directory


When "partial" is specified, "merge.update" doesn't update dirstate
entries for standins, even though standins themselves are updated.

In this case, "normallookup" should be used to mark largefiles as
"possibly dirty" forcibly, because applying "normal" on lfdirstate
treats them as "clean" unexpectedly.

This is reason why "normallookup=partial" is specified for
"lfcommands.updatelfiles".


This patch doesn't test "hg rebase --continue", because it doesn't
work correctly if largefiles in the working directory are modified
manually while resolving conflicts. This will be fixed in the next
step of refactoring for largefiles.

All changes of tests/*.t files other than test-largefiles-update.t in
this patch come from invoking "updatelfiles" not after but before
statistics output of "hg.update", "hg.clean" and "hg.merge".
largefiles: update largefiles even if transplant is aborted by conflict

Before this patch, largefiles in the working directory aren't updated
correctly, if transplant is aborted by conflict. This prevents users
from viewing appropriate largefiles while resolving conflicts.

While transplant, largefiles in the working directory are updated only
at successful committing in the special code path of
"lfilesrepo.commit()".

To update largefiles even if transplant is aborted by conflict, this
patch wraps "scmutil.marktouched", which is invoked from "patch.patch"
with "files" list of added/modified/deleted files.

This patch invokes "updatelfiles" with:

  - "printmessage=False", to suppress "getting changed largefiles ..."
    messages while automated committing by transplant

  - "normallookup=True", because "patch.patch" doesn't update dirstate
    for modified files

    in such case, "normallookup=False" may cause marking modified
    largefiles as "clean" unexpectedly
largefiles: remove redundant "updatelfiles" invocation in "lfilesrepo.commit"

After previous patches, largefiles in the working directory are
ensured to be updated before "repo.commit" invocation for automated
committing below:

  - by "overrides.mergeupdate" via "merge.update" for rebase
  - by "overrides.scmutilmarktouched" via "patch.patch" for transplant

This patch removes redundant "lfcommands.updatelfiles" invocation in
"Case 0" code path of "lfilesrepo.commit" for automated committing,
and revises detailed comment.
ui: add brief comment why raw_input() needs dummy ' ' prompt string

Retrieved from 17ffb30d9174.

I was about to move ' ' to label(msg + ' ', 'ui.prompt') so that subclass can
distinguish prompt output from data.  But it was not that simple.

--HG--
extra : rebase_source : ce6323e96cd998431a0debc04758d45691934d70
run-tests: report skipped tests as "skipped" - they might still be "relevant"

--HG--
extra : rebase_source : c2d91f9afd2a74231ab888fb9c0b42b64063f93d
tests: fix p4 tests so they use separate ports and can be run in parallel

--HG--
extra : rebase_source : 50c9d300fa6e746c97d44014665a8a494e20710e
convert: p4: ignore purged files with p4d 2012.2 and later

Perforce has the concept of "+Sn" files where only the last revisions of the
file is stored. In p4d 2012.1 old purged revisions were not included in the
"manifest". With 2012.2 they started being included and convert's getfile
failed to recognize the "purged" flag and saw it as an empty file. That made
test-convert-p4-filetypes.t fail.

There is no point in storing an empty file as placeholder for a purged file so
we restore the old behaviour by checking the flag and letting getfile consider
purged files deleted.

(It is questionable whether it makes sense to convert not-yet-purged +S files
to mercurial ... but that is another question.)

--HG--
extra : rebase_source : dc5d92090443fc8eba5b686b6ba51db1ef1739fc
help: add pad function to template help

Commit aa51392da507 introduced a pad function for use in templates, but did
not add the corresponding documentation to 'hg help templating'.

--HG--
branch : stable
extra : rebase_source : 211b3c671d9d2585a0fd745dcca3b07b00c8316f
merge with stable