Mercurial > hg
view contrib/plan9/README @ 21932:21a2f31f054d stable
largefiles: use "normallookup", if "mtime" of standin is unset
Before this patch, largefiles gotten from "other" revision (without
conflict) at "hg merge" become "clean" unexpectedly in steps below:
1. "merge.update()" is invoked
1-1 standinfile SF is updated in the working directory
1-2 "dirstate" entry for SF is "normallookup"-ed
2. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
2-1 largefile LF (for SF) is updated in the working directory
2-2 "dirstate" returns "n" for SF (by 1-2)
2-3 "lfdirstate" entry for LF is "normal"-ed
2-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
timestamp of LF is stored into "lfdirstate" file
(ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 2-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 2-3 and 2-4) as "clean".
When timestamp is not set (= negative value) for standinfile in
"dirstate", largefile should be "normallookup"-ed regardless of
rebasing or not, because "n" state in "dirstate" doesn't ensure
"clean"-ness of a standinfile at that time.
This patch uses "normallookup" instead of "normal", if "mtime" of
standin is unset
This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, "lfdirstate" should
be updated with "dirstate" simultaneously while "merge.update"
execution: maybe by hooking "recordupdates"
It is also why this patch (temporarily) uses internal field "_map" of
"dirstate" directly.
This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 2-4)
This patch newly adds "test-largefiles-update.t", to avoid increasing
cost to run other tests for largefiles by subsequent patches
(especially, "[debug] dirstate.delaywrite" causes so).
author | FUJIWARA Katsunori <foozy@lares.dti.ne.jp> |
---|---|
date | Tue, 22 Jul 2014 23:59:34 +0900 |
parents | f5dd179bfa4a |
children | 4b0fc75f9403 |
line wrap: on
line source
Mercurial for Plan 9 from Bell Labs =================================== This directory contains support for Mercurial on Plan 9 from Bell Labs platforms. It is assumed that the version of Python running on these systems supports the ANSI/POSIX Environment (APE). At the time of this writing, the bichued/python port is the most commonly installed version of Python on these platforms. If a native port of Python is ever made, some minor modification will need to be made to support some of the more esoteric requirements of the platform rather than those currently made (cf. posix.py). By default, installations will have the factotum extension enabled; this extension permits factotum(4) to act as an authentication agent for HTTP repositories. Additionally, an extdiff command named 9diff is enabled which generates diff(1) compatible output suitable for use with the plumber(4). Commit messages are plumbed using E if no editor is defined; users must update the plumbed file to continue, otherwise the hg process must be interrupted. Some work remains with regard to documentation. Section 5 manual page references for hgignore and hgrc need to be re-numbered to section 6 (file formats) and a new man page writer should be written to support the Plan 9 man macro set. Until these issues can be resolved, manual pages are elided from the installation. Basic install: % mk install # do a system-wide install % hg debuginstall # sanity-check setup % hg # see help A proto(2) file is included in this directory as an example of how a binary distribution could be packaged, ostensibly with contrib(1). See http://mercurial.selenic.com/ for detailed installation instructions, platform-specific notes, and Mercurial user information.