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

tests: fix p4 tests so they use separate ports and can be run in parallel

run-tests: report skipped tests as "skipped" - they might still be "relevant"

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.

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.

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

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.

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.

repoview: fix 0L with pack/unpack for 2.4

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