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