graft: fix collision detection with origin revisions that are missing When grafting something with a matching origin, it would normally be skipped: skipping already grafted revision 123 (23 also has origin 12) But after stripping a graft origin, graft could fail with a reference to the origin that no longer exists: abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'! Instead, detect that the origin is unknown and skip it anyway, like: skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)

log: use correct phase info for parent field (issue4347) Previously, there was a copy / paste error with using the current changeset's phase information. We now look up the parent context explicitly. The line was too long so it is stored into a variable first.

convert: introduce --full for converting all files Convert will normally only process files that were changed in a source revision, apply the filemap, and record it has a change in the target repository. (If it ends up not really changing anything, nothing changes.) That means that _if_ the filemap is changed before continuing an incremental convert, the change will only kick in when the files it affects are modified in a source revision and thus processed. With --full, convert will make a full conversion every time and process all files in the source repo and remove target repo files that shouldn't be there. Filemap changes will thus kick in on the first converted revision, no matter what is changed. This flag should in most cases not make any difference but will make convert significantly slower. Other names has been considered for this feature, such as "resync", "sync", "checkunmodified", "all" or "allfiles", but I found that they were less obvious and required more explanation than "full" and were harder to describe consistently.

convert: refactor hg getchanges and caching

convert: refactor subversion getchanges and caching

convert: remove incorrect and unused handling of removed svn directories Since it was introduced in f0c58fd4b798, tidy_dirs has been comparing the result of os.listdir with a string - which never can be true. Convert apparently works anyway and there is no test coverage of it. It also seems like it could make a bigger difference on older svn versions but is less relevant with more recent versions. Instead of trying to fix the code, we take the low risk option and remove it.

convert: use None value for missing files instead of overloading IOError The internal API used IOError to indicate that a file should be marked as removed. There is some correlation between IOError (especially with ENOENT) and files that should be removed, but using IOErrors to represent file removal internally required some hacks. Instead, use the value None to indicate that the file not is present. Before, spurious IO errors could cause commits that silently removed files. They will now be reported like all other IO errors so the root cause can be fixed.

merge with stable

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

histedit: use str.startswith to check for comments in action list

histedit: drop duplicate line extracting keep option

import: avoid editor invocation when importing with "--exact" for exact-ness Before this patch, external editor is invoked when imported patch has no commit message, even if "--exact" is specified. Then, exact-ness is broken, because empty commit message causes failure of committing. This patch avoids editor invocation at importing with "--exact" for exact-ness, because commit message in the patch should be kept as it is in such case, even if it is empty.

import: disallow meaningless combination of "--exact" and "--edit" Before this patch, "hg import" allows combination of "--exact" and "--edit", even though editing commit message breaks exact-ness. This patch disallows meaningless combination of "--exact" and "--edit".

config: highlight parse error caused by leading spaces (issue3214) Added "unexpected leading whitespace" message to parse error when .hgrc has a line that starts with whitespace. Helps new users unfamiliar with syntax of rc file.

test-config: add tests for invalid syntax This was not tested and there is more to come in the next patch.