facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 15:27:13 +03:00
Code Issues Projects Releases Wiki Activity
66766c7b03
sapling/tests/test-largefiles-update.t

695 lines
20 KiB
Perl
Raw Normal View History

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).
2014-07-22 18:59:34 +04:00
This file focuses mainly on updating largefiles in the working
directory (and ".hg/largefiles/dirstate")
$ cat >> $HGRCPATH <<EOF
> [ui]
> merge = internal:fail
> [extensions]
> largefiles =
> EOF
$ hg init repo
$ cd repo
$ echo large1 > large1
$ echo large2 > large2
$ hg add --large large1 large2
$ echo normal1 > normal1
$ hg add normal1
$ hg commit -m '#0'
$ echo 'large1 in #1' > large1
$ echo 'normal1 in #1' > normal1
$ hg commit -m '#1'
$ hg update -q -C 0
$ echo 'large2 in #2' > large2
$ hg commit -m '#2'
created new head
largefiles: make linear update set unsure largefiles normal if unchanged 'hg update' would hash all 'unsure' largefiles before performing the merge. It would update the standins but not detect the very common case where the largefile never had been changed by the user but just had been marked with an invalid dirstate mtime to make sure any changes done by the user in the same second would be detected. The largefile would remain in that state and would have to be hashed again next time even though it still not had been changed. Sad trombone. Instead, for largefiles listed as 'unsure' or 'modified', after updating the standin with the actual hash, mark the largefile as normal if it turns out to not be modified relative to the revision in the parent revision. That will prevent it from being hashed again next time.
2015-01-09 20:38:02 +03:00
Test that update also updates the lfdirstate of 'unsure' largefiles after
hashing them:
The previous operations will usually have left us with largefiles with a mtime
within the same second as the dirstate was written.
The lfdirstate entries will thus have been written with an invalidated/unset
mtime to make sure further changes within the same second is detected.
We will however occasionally be "lucky" and get a tick between writing
largefiles and writing dirstate so we get valid lfdirstate timestamps. The
following verification is thus disabled but can be verified manually.
#if false
$ hg debugdirstate --large --nodate
n 644 7 unset large1
n 644 13 unset large2
#endif
Wait to make sure we get a tick so the mtime of the largefiles become valid.
$ sleep 1
A linear merge will update standins before performing the actual merge. It will
do a lfdirstate status walk and find 'unset'/'unsure' files, hash them, and
update the corresponding standins.
Verify that it actually marks the clean files as clean in lfdirstate so
we don't have to hash them again next time we update.
$ hg up
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg debugdirstate --large --nodate
n 644 7 set large1
n 644 13 set large2
tests: add test coverage for lfdirstate invalidation of linear update d20af8be6a14 introduced a significant performance regression: All largefiles are marked 'normallookup' in lfdirstate by linear (or noop) updates and has to be rehashed by the next command. To avoid such regressions, keep an eye on the dirstate content after a plain 'hg up'.
2014-12-31 16:45:02 +03:00
Test that lfdirstate keeps track of last modification of largefiles and
prevents unnecessary hashing of content - also after linear/noop update
$ sleep 1
$ hg st
$ hg debugdirstate --large --nodate
debugdirstate: don't hide date field with --nodate, just show 'set'/'unset' The value of the dirstate date field cannot be used in tests and we thus have to use debugdirstate with --nodate. It is however still very helpful to be able to see whether the date field has been set or still is unset. The absence of that information made it hard to debug some largefile dirstate issues. This change _could_ make the test suite more unstable ... but that would be places where the test suite or the code should be made more stable. (Note: 'unset' with the magic negative sizes is reliable. 'unset' for normal sizes would probably not be reliable, but there is no such occurrences in the test suite and it should thus be reliable.) This output wastes more horizontal space in the --nodate output, but it also makes things simpler that the output format always is the same. It is just a debug command so let's keep it simple.
2015-01-09 20:38:02 +03:00
n 644 7 set large1
n 644 13 set large2
tests: add test coverage for lfdirstate invalidation of linear update d20af8be6a14 introduced a significant performance regression: All largefiles are marked 'normallookup' in lfdirstate by linear (or noop) updates and has to be rehashed by the next command. To avoid such regressions, keep an eye on the dirstate content after a plain 'hg up'.
2014-12-31 16:45:02 +03:00
$ hg up
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg debugdirstate --large --nodate
debugdirstate: don't hide date field with --nodate, just show 'set'/'unset' The value of the dirstate date field cannot be used in tests and we thus have to use debugdirstate with --nodate. It is however still very helpful to be able to see whether the date field has been set or still is unset. The absence of that information made it hard to debug some largefile dirstate issues. This change _could_ make the test suite more unstable ... but that would be places where the test suite or the code should be made more stable. (Note: 'unset' with the magic negative sizes is reliable. 'unset' for normal sizes would probably not be reliable, but there is no such occurrences in the test suite and it should thus be reliable.) This output wastes more horizontal space in the --nodate output, but it also makes things simpler that the output format always is the same. It is just a debug command so let's keep it simple.
2015-01-09 20:38:02 +03:00
n 644 7 set large1
n 644 13 set large2
tests: add test coverage for lfdirstate invalidation of linear update d20af8be6a14 introduced a significant performance regression: All largefiles are marked 'normallookup' in lfdirstate by linear (or noop) updates and has to be rehashed by the next command. To avoid such regressions, keep an eye on the dirstate content after a plain 'hg up'.
2014-12-31 16:45:02 +03:00
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).
2014-07-22 18:59:34 +04:00
Test that "hg merge" updates largefiles from "other" correctly
(getting largefiles from "other" normally)
$ hg status -A large1
C large1
$ cat large1
large1
$ cat .hglf/large1
4669e532d5b2c093a78eca010077e708a071bb64
$ hg merge --config debug.dirstate.delaywrite=2
getting changed largefiles
1 largefiles updated, 0 removed
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".
2014-08-24 18:47:26 +04:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
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).
2014-07-22 18:59:34 +04:00
$ hg status -A large1
M large1
$ cat large1
large1 in #1
$ cat .hglf/large1
58e24f733a964da346e2407a2bee99d9001184f5
$ hg diff -c 1 --nodates .hglf/large1 | grep '^[+-][0-9a-z]'
-4669e532d5b2c093a78eca010077e708a071bb64
+58e24f733a964da346e2407a2bee99d9001184f5
largefiles: invoke "normallookup" on "lfdirstate" for merged files Before this patch, largefiles gotten from "other" revision (with conflict) at "hg merge" become "clean" unexpectedly in steps below: 1. "repo.status()" is invoked (for status check before merging) 1-1 "dirstate" entry for standinfile SF is "normal"-ed 1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed 2. "merge.update()" is invoked 2-1 SF is updated in the working directory (ASSUMPTION: user choice "other" at conflict) 2-2 "dirstate" entry for SF is "merge"-ed 3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()") 3-1 largefile LF (for SF) is updated in the working directory 3-2 "dirstate" returns "m" for SF (by 2-2) 3-3 "lfdirstate" entry for LF is left as it is 3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (by 1-2) (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 3-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 1-2 and 3-4) as "clean". When state of standinfile in "dirstate" is "m", largefile should be "normallookup"-ed. This patch invokes "normallookup" on "lfdirstate" for merged files. 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 3-4)
2014-07-22 19:10:24 +04:00
(getting largefiles from "other" via conflict prompt)
$ hg update -q -C 2
$ echo 'large1 in #3' > large1
$ echo 'normal1 in #3' > normal1
$ hg commit -m '#3'
$ cat .hglf/large1
e5bb990443d6a92aaf7223813720f7566c9dd05b
$ hg merge --config debug.dirstate.delaywrite=2 --config ui.interactive=True <<EOF
> o
> EOF
largefile large1 has a merge conflict
ancestor was 4669e532d5b2c093a78eca010077e708a071bb64
keep (l)ocal e5bb990443d6a92aaf7223813720f7566c9dd05b or
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
take (o)ther 58e24f733a964da346e2407a2bee99d9001184f5? o
merging normal1
largefiles: invoke "normallookup" on "lfdirstate" for merged files Before this patch, largefiles gotten from "other" revision (with conflict) at "hg merge" become "clean" unexpectedly in steps below: 1. "repo.status()" is invoked (for status check before merging) 1-1 "dirstate" entry for standinfile SF is "normal"-ed 1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed 2. "merge.update()" is invoked 2-1 SF is updated in the working directory (ASSUMPTION: user choice "other" at conflict) 2-2 "dirstate" entry for SF is "merge"-ed 3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()") 3-1 largefile LF (for SF) is updated in the working directory 3-2 "dirstate" returns "m" for SF (by 2-2) 3-3 "lfdirstate" entry for LF is left as it is 3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (by 1-2) (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 3-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 1-2 and 3-4) as "clean". When state of standinfile in "dirstate" is "m", largefile should be "normallookup"-ed. This patch invokes "normallookup" on "lfdirstate" for merged files. 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 3-4)
2014-07-22 19:10:24 +04:00
warning: conflicts during merge.
merging normal1 incomplete! (edit conflicts, then use 'hg resolve --mark')
getting changed largefiles
1 largefiles updated, 0 removed
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".
2014-08-24 18:47:26 +04:00
0 files updated, 1 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
largefiles: invoke "normallookup" on "lfdirstate" for merged files Before this patch, largefiles gotten from "other" revision (with conflict) at "hg merge" become "clean" unexpectedly in steps below: 1. "repo.status()" is invoked (for status check before merging) 1-1 "dirstate" entry for standinfile SF is "normal"-ed 1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed 2. "merge.update()" is invoked 2-1 SF is updated in the working directory (ASSUMPTION: user choice "other" at conflict) 2-2 "dirstate" entry for SF is "merge"-ed 3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()") 3-1 largefile LF (for SF) is updated in the working directory 3-2 "dirstate" returns "m" for SF (by 2-2) 3-3 "lfdirstate" entry for LF is left as it is 3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (by 1-2) (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 3-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 1-2 and 3-4) as "clean". When state of standinfile in "dirstate" is "m", largefile should be "normallookup"-ed. This patch invokes "normallookup" on "lfdirstate" for merged files. 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 3-4)
2014-07-22 19:10:24 +04:00
[1]
$ hg status -A large1
M large1
$ cat large1
large1 in #1
$ cat .hglf/large1
58e24f733a964da346e2407a2bee99d9001184f5
largefiles: use "normallookup" on "lfdirstate" while reverting Before this patch, largefiles gotten from revisions other than the parent of the working directory at "hg revert" become "clean" unexpectedly in steps below: 1. "repo.status()" is invoked (for status check before reverting) 1-1 "dirstate" entry for standinfile SF is "normal"-ed (1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed) 2. "cmdutil.revert()" is invoked 2-1 standinfile SF is updated in the working directory 2-2 "dirstate" entry for SF is NOT updated 3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()") 3-1 largefile LF (for SF) is updated in the working directory 3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2) 3-3 "lfdirstate" entry for LF is "normal"-ed 3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (by 3-3) (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 3-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 3-3 and 3-4) as "clean". When largefiles are reverted, they should be "normallookup"-ed forcibly. This patch uses "normallookup" on "lfdirstate" while reverting, by passing "True" to newly added argument "normallookup". Forcible "normallookup"-ing is not so expensive, because list of target largefiles is explicitly specified in this case. 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 3-4)
2014-07-22 19:10:24 +04:00
Test that "hg revert -r REV" updates largefiles from "REV" correctly
$ hg update -q -C 3
$ hg status -A large1
C large1
$ cat large1
large1 in #3
$ cat .hglf/large1
e5bb990443d6a92aaf7223813720f7566c9dd05b
$ hg diff -c 1 --nodates .hglf/large1 | grep '^[+-][0-9a-z]'
-4669e532d5b2c093a78eca010077e708a071bb64
+58e24f733a964da346e2407a2bee99d9001184f5
$ hg revert --no-backup -r 1 --config debug.dirstate.delaywrite=2 large1
$ hg status -A large1
M large1
$ cat large1
large1 in #1
$ cat .hglf/large1
58e24f733a964da346e2407a2bee99d9001184f5
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
Test that "hg rollback" restores status of largefiles correctly
$ hg update -C -q
$ hg remove large1
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.
2014-08-24 18:47:25 +04:00
$ test -f .hglf/large1
[1]
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg forget large2
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.
2014-08-24 18:47:25 +04:00
$ test -f .hglf/large2
[1]
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ echo largeX > largeX
$ hg add --large largeX
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.
2014-08-24 18:47:25 +04:00
$ cat .hglf/largeX
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg commit -m 'will be rollback-ed soon'
largefiles: drop orphan entries from lfdristat at "hg rollback" Before this patch, newly added (but not yet committed) largefiles aren't treated as unknown ("?") after "hg rollback". After "hg rollback", lfdirstate still contains "A" status entries for such largefiles, even though corresponding entries for standins are already dropped from dirstate. Such "orphan" entries in lfdirstate prevent unknown (large)files in the working directory from being listed up in "unknown" list. The code path in "if working" route of "lfilesrepo.status" below drops largefiles tracked in lfdirstate from "unknown" list: lfiles = set(lfdirstate._map) # Unknown files result[4] = set(result[4]).difference(lfiles) This patch drops orphan entries from lfdristate at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ echo largeY > largeY
$ hg add --large largeY
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#if windows
$ hg status -A large1
large1: * (glob)
#else
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg status -A large1
large1: No such file or directory
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#endif
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg status -A large2
? large2
$ hg status -A largeX
C largeX
largefiles: drop orphan entries from lfdristat at "hg rollback" Before this patch, newly added (but not yet committed) largefiles aren't treated as unknown ("?") after "hg rollback". After "hg rollback", lfdirstate still contains "A" status entries for such largefiles, even though corresponding entries for standins are already dropped from dirstate. Such "orphan" entries in lfdirstate prevent unknown (large)files in the working directory from being listed up in "unknown" list. The code path in "if working" route of "lfilesrepo.status" below drops largefiles tracked in lfdirstate from "unknown" list: lfiles = set(lfdirstate._map) # Unknown files result[4] = set(result[4]).difference(lfiles) This patch drops orphan entries from lfdristate at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg status -A largeY
A largeY
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg rollback
repository tip rolled back to revision 3 (undo commit)
working directory now based on revision 3
$ hg status -A large1
R large1
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.
2014-08-24 18:47:25 +04:00
$ test -f .hglf/large1
[1]
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg status -A large2
R large2
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.
2014-08-24 18:47:25 +04:00
$ test -f .hglf/large2
[1]
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg status -A largeX
A largeX
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.
2014-08-24 18:47:25 +04:00
$ cat .hglf/largeX
largefiles: drop orphan entries from lfdristat at "hg rollback" Before this patch, newly added (but not yet committed) largefiles aren't treated as unknown ("?") after "hg rollback". After "hg rollback", lfdirstate still contains "A" status entries for such largefiles, even though corresponding entries for standins are already dropped from dirstate. Such "orphan" entries in lfdirstate prevent unknown (large)files in the working directory from being listed up in "unknown" list. The code path in "if working" route of "lfilesrepo.status" below drops largefiles tracked in lfdirstate from "unknown" list: lfiles = set(lfdirstate._map) # Unknown files result[4] = set(result[4]).difference(lfiles) This patch drops orphan entries from lfdristate at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
$ hg status -A largeY
? largeY
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.
2014-08-24 18:47:26 +04:00
$ test -f .hglf/largeY
[1]
largefiles: restore R status of removed largefiles correctly at "hg rollback" Before this patch, removed or forgotten largefiles aren't treated as removed ("R") after "hg rollback". Removed ones are treated as missing ("!") and forgotten ones are treated as clean ("C") unexpectedly. "overriderollback" uses "normallookup" to restore status in lfdirstate for largefiles other than ones not added in rollback-ed revision, but this isn't correct for removed (or forgotten) largefiles. This patch uses "lfutil.synclfdirstate" to restore "R" status of removed (or forgotten) largefiles correctly at "hg rollback". This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, lfdirstate should be rollback-ed as a part of transaction, as same as dirstate.
2014-08-11 17:29:43 +04:00
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.
2014-08-24 18:47:25 +04:00
Test that "hg rollback" restores standins correctly
$ hg commit -m 'will be rollback-ed soon'
$ hg update -q -C 2
$ cat large1
large1
$ cat .hglf/large1
4669e532d5b2c093a78eca010077e708a071bb64
$ cat large2
large2 in #2
$ cat .hglf/large2
3cfce6277e7668985707b6887ce56f9f62f6ccd9
$ hg rollback -q -f
$ cat large1
large1
$ cat .hglf/large1
4669e532d5b2c093a78eca010077e708a071bb64
$ cat large2
large2 in #2
$ cat .hglf/large2
3cfce6277e7668985707b6887ce56f9f62f6ccd9
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.
2014-08-24 18:47:25 +04:00
(rollback the parent of the working directory, when the parent of it
is not branch-tip)
$ hg update -q -C 1
$ cat .hglf/large1
58e24f733a964da346e2407a2bee99d9001184f5
$ cat .hglf/large2
1deebade43c8c498a3c8daddac0244dc55d1331d
$ echo normalX > normalX
$ hg add normalX
$ hg commit -m 'will be rollback-ed soon'
$ hg rollback -q
$ cat .hglf/large1
58e24f733a964da346e2407a2bee99d9001184f5
$ cat .hglf/large2
1deebade43c8c498a3c8daddac0244dc55d1331d
largefiles: synchronize lfdirstate with dirstate after automated committing Before this patch, after successful "hg rebase" of the revision removing largefiles, "hg status" may still show ""R" for such largefiles unexpectedly. "lfilesrepo.commit" executes the special code path for automated committing while rebase/transplant, and lfdirstate entries for removed files aren't updated in this code path, even after successful committing. Then, "R" entries still existing in lfdirstate cause unexpected "hg status" output. This patch synchronizes lfdirstate with dirstate after automated committing. This patch passes False as "normallookup" to "synclfdirstate", because modified files in "files()" of the recent (= just committed) context should be "normal"-ed. 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. Hooking "markcommitted" of ctx in "localrepository.commitctx" may achieve this. This problem occurs, only when (1) the parent of the working directory is rebased and (2) it removes largefiles, because: - if the parent of the working directory isn't rebased, returning to the initial revision (= update) after rebase hides this problem - files added on "other" branch (= rebase target) are treated not as "added" but as "modified" (= "normal" status and "unset" timestamp) at merging This patch tests also the status of added largefile, but it is only for avoiding regression. In addition to conditions above, "hg status" must not take existing files to reproduce this problem, because existing files make "match._files" not empty in "lfilesrepo.status" code path below: def sfindirstate(f): sf = lfutil.standin(f) dirstate = self.dirstate return sf in dirstate or sf in dirstate.dirs() match._files = [f for f in match._files if sfindirstate(f)] Not empty "match._files" prevents "status" on lfdirstate from returning the result containing problematic "R" files. This is reason why "large1" (removed) and "largeX" (added) are checked separately in this patch. Problematic code path in "lfilesrepo.commit" is used also by "hg transplant", but this problem doesn't occur at "hg transplant", because invocation of "updatelfiles" after transplant-ing in "overridetransplant" causes cleaning lfdirstate up. This patch tests also "hg transplant" as same as "hg rebase", but it is only for avoiding regression.
2014-08-11 17:29:43 +04:00
Test that "hg status" shows status of largefiles correctly just after
automated commit like rebase/transplant
$ cat >> .hg/hgrc <<EOF
> [extensions]
> rebase =
> strip =
> transplant =
> EOF
$ hg update -q -C 1
$ hg remove large1
$ echo largeX > largeX
$ hg add --large largeX
$ hg commit -m '#4'
$ hg rebase -s 1 -d 2 --keep
rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
2014-12-09 05:45:26 +03:00
rebasing 1:72518492caa6 "#1"
rebasing 4:07d6153b5c04 "#4" (tip)
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#if windows
$ hg status -A large1
large1: * (glob)
#else
largefiles: synchronize lfdirstate with dirstate after automated committing Before this patch, after successful "hg rebase" of the revision removing largefiles, "hg status" may still show ""R" for such largefiles unexpectedly. "lfilesrepo.commit" executes the special code path for automated committing while rebase/transplant, and lfdirstate entries for removed files aren't updated in this code path, even after successful committing. Then, "R" entries still existing in lfdirstate cause unexpected "hg status" output. This patch synchronizes lfdirstate with dirstate after automated committing. This patch passes False as "normallookup" to "synclfdirstate", because modified files in "files()" of the recent (= just committed) context should be "normal"-ed. 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. Hooking "markcommitted" of ctx in "localrepository.commitctx" may achieve this. This problem occurs, only when (1) the parent of the working directory is rebased and (2) it removes largefiles, because: - if the parent of the working directory isn't rebased, returning to the initial revision (= update) after rebase hides this problem - files added on "other" branch (= rebase target) are treated not as "added" but as "modified" (= "normal" status and "unset" timestamp) at merging This patch tests also the status of added largefile, but it is only for avoiding regression. In addition to conditions above, "hg status" must not take existing files to reproduce this problem, because existing files make "match._files" not empty in "lfilesrepo.status" code path below: def sfindirstate(f): sf = lfutil.standin(f) dirstate = self.dirstate return sf in dirstate or sf in dirstate.dirs() match._files = [f for f in match._files if sfindirstate(f)] Not empty "match._files" prevents "status" on lfdirstate from returning the result containing problematic "R" files. This is reason why "large1" (removed) and "largeX" (added) are checked separately in this patch. Problematic code path in "lfilesrepo.commit" is used also by "hg transplant", but this problem doesn't occur at "hg transplant", because invocation of "updatelfiles" after transplant-ing in "overridetransplant" causes cleaning lfdirstate up. This patch tests also "hg transplant" as same as "hg rebase", but it is only for avoiding regression.
2014-08-11 17:29:43 +04:00
$ hg status -A large1
large1: No such file or directory
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#endif
largefiles: synchronize lfdirstate with dirstate after automated committing Before this patch, after successful "hg rebase" of the revision removing largefiles, "hg status" may still show ""R" for such largefiles unexpectedly. "lfilesrepo.commit" executes the special code path for automated committing while rebase/transplant, and lfdirstate entries for removed files aren't updated in this code path, even after successful committing. Then, "R" entries still existing in lfdirstate cause unexpected "hg status" output. This patch synchronizes lfdirstate with dirstate after automated committing. This patch passes False as "normallookup" to "synclfdirstate", because modified files in "files()" of the recent (= just committed) context should be "normal"-ed. 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. Hooking "markcommitted" of ctx in "localrepository.commitctx" may achieve this. This problem occurs, only when (1) the parent of the working directory is rebased and (2) it removes largefiles, because: - if the parent of the working directory isn't rebased, returning to the initial revision (= update) after rebase hides this problem - files added on "other" branch (= rebase target) are treated not as "added" but as "modified" (= "normal" status and "unset" timestamp) at merging This patch tests also the status of added largefile, but it is only for avoiding regression. In addition to conditions above, "hg status" must not take existing files to reproduce this problem, because existing files make "match._files" not empty in "lfilesrepo.status" code path below: def sfindirstate(f): sf = lfutil.standin(f) dirstate = self.dirstate return sf in dirstate or sf in dirstate.dirs() match._files = [f for f in match._files if sfindirstate(f)] Not empty "match._files" prevents "status" on lfdirstate from returning the result containing problematic "R" files. This is reason why "large1" (removed) and "largeX" (added) are checked separately in this patch. Problematic code path in "lfilesrepo.commit" is used also by "hg transplant", but this problem doesn't occur at "hg transplant", because invocation of "updatelfiles" after transplant-ing in "overridetransplant" causes cleaning lfdirstate up. This patch tests also "hg transplant" as same as "hg rebase", but it is only for avoiding regression.
2014-08-11 17:29:43 +04:00
$ hg status -A largeX
C largeX
$ hg strip -q 5
$ hg update -q -C 2
$ hg transplant -q 1 4
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#if windows
$ hg status -A large1
large1: * (glob)
#else
largefiles: synchronize lfdirstate with dirstate after automated committing Before this patch, after successful "hg rebase" of the revision removing largefiles, "hg status" may still show ""R" for such largefiles unexpectedly. "lfilesrepo.commit" executes the special code path for automated committing while rebase/transplant, and lfdirstate entries for removed files aren't updated in this code path, even after successful committing. Then, "R" entries still existing in lfdirstate cause unexpected "hg status" output. This patch synchronizes lfdirstate with dirstate after automated committing. This patch passes False as "normallookup" to "synclfdirstate", because modified files in "files()" of the recent (= just committed) context should be "normal"-ed. 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. Hooking "markcommitted" of ctx in "localrepository.commitctx" may achieve this. This problem occurs, only when (1) the parent of the working directory is rebased and (2) it removes largefiles, because: - if the parent of the working directory isn't rebased, returning to the initial revision (= update) after rebase hides this problem - files added on "other" branch (= rebase target) are treated not as "added" but as "modified" (= "normal" status and "unset" timestamp) at merging This patch tests also the status of added largefile, but it is only for avoiding regression. In addition to conditions above, "hg status" must not take existing files to reproduce this problem, because existing files make "match._files" not empty in "lfilesrepo.status" code path below: def sfindirstate(f): sf = lfutil.standin(f) dirstate = self.dirstate return sf in dirstate or sf in dirstate.dirs() match._files = [f for f in match._files if sfindirstate(f)] Not empty "match._files" prevents "status" on lfdirstate from returning the result containing problematic "R" files. This is reason why "large1" (removed) and "largeX" (added) are checked separately in this patch. Problematic code path in "lfilesrepo.commit" is used also by "hg transplant", but this problem doesn't occur at "hg transplant", because invocation of "updatelfiles" after transplant-ing in "overridetransplant" causes cleaning lfdirstate up. This patch tests also "hg transplant" as same as "hg rebase", but it is only for avoiding regression.
2014-08-11 17:29:43 +04:00
$ hg status -A large1
large1: No such file or directory
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#endif
largefiles: synchronize lfdirstate with dirstate after automated committing Before this patch, after successful "hg rebase" of the revision removing largefiles, "hg status" may still show ""R" for such largefiles unexpectedly. "lfilesrepo.commit" executes the special code path for automated committing while rebase/transplant, and lfdirstate entries for removed files aren't updated in this code path, even after successful committing. Then, "R" entries still existing in lfdirstate cause unexpected "hg status" output. This patch synchronizes lfdirstate with dirstate after automated committing. This patch passes False as "normallookup" to "synclfdirstate", because modified files in "files()" of the recent (= just committed) context should be "normal"-ed. 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. Hooking "markcommitted" of ctx in "localrepository.commitctx" may achieve this. This problem occurs, only when (1) the parent of the working directory is rebased and (2) it removes largefiles, because: - if the parent of the working directory isn't rebased, returning to the initial revision (= update) after rebase hides this problem - files added on "other" branch (= rebase target) are treated not as "added" but as "modified" (= "normal" status and "unset" timestamp) at merging This patch tests also the status of added largefile, but it is only for avoiding regression. In addition to conditions above, "hg status" must not take existing files to reproduce this problem, because existing files make "match._files" not empty in "lfilesrepo.status" code path below: def sfindirstate(f): sf = lfutil.standin(f) dirstate = self.dirstate return sf in dirstate or sf in dirstate.dirs() match._files = [f for f in match._files if sfindirstate(f)] Not empty "match._files" prevents "status" on lfdirstate from returning the result containing problematic "R" files. This is reason why "large1" (removed) and "largeX" (added) are checked separately in this patch. Problematic code path in "lfilesrepo.commit" is used also by "hg transplant", but this problem doesn't occur at "hg transplant", because invocation of "updatelfiles" after transplant-ing in "overridetransplant" causes cleaning lfdirstate up. This patch tests also "hg transplant" as same as "hg rebase", but it is only for avoiding regression.
2014-08-11 17:29:43 +04:00
$ hg status -A largeX
C largeX
$ hg strip -q 5
$ hg update -q -C 2
$ hg transplant -q --merge 1 --merge 4
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#if windows
$ hg status -A large1
large1: * (glob)
#else
largefiles: synchronize lfdirstate with dirstate after automated committing Before this patch, after successful "hg rebase" of the revision removing largefiles, "hg status" may still show ""R" for such largefiles unexpectedly. "lfilesrepo.commit" executes the special code path for automated committing while rebase/transplant, and lfdirstate entries for removed files aren't updated in this code path, even after successful committing. Then, "R" entries still existing in lfdirstate cause unexpected "hg status" output. This patch synchronizes lfdirstate with dirstate after automated committing. This patch passes False as "normallookup" to "synclfdirstate", because modified files in "files()" of the recent (= just committed) context should be "normal"-ed. 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. Hooking "markcommitted" of ctx in "localrepository.commitctx" may achieve this. This problem occurs, only when (1) the parent of the working directory is rebased and (2) it removes largefiles, because: - if the parent of the working directory isn't rebased, returning to the initial revision (= update) after rebase hides this problem - files added on "other" branch (= rebase target) are treated not as "added" but as "modified" (= "normal" status and "unset" timestamp) at merging This patch tests also the status of added largefile, but it is only for avoiding regression. In addition to conditions above, "hg status" must not take existing files to reproduce this problem, because existing files make "match._files" not empty in "lfilesrepo.status" code path below: def sfindirstate(f): sf = lfutil.standin(f) dirstate = self.dirstate return sf in dirstate or sf in dirstate.dirs() match._files = [f for f in match._files if sfindirstate(f)] Not empty "match._files" prevents "status" on lfdirstate from returning the result containing problematic "R" files. This is reason why "large1" (removed) and "largeX" (added) are checked separately in this patch. Problematic code path in "lfilesrepo.commit" is used also by "hg transplant", but this problem doesn't occur at "hg transplant", because invocation of "updatelfiles" after transplant-ing in "overridetransplant" causes cleaning lfdirstate up. This patch tests also "hg transplant" as same as "hg rebase", but it is only for avoiding regression.
2014-08-11 17:29:43 +04:00
$ hg status -A large1
large1: No such file or directory
tests: add "(glob)" for l10n messages in test-largefiles-update.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#endif
largefiles: synchronize lfdirstate with dirstate after automated committing Before this patch, after successful "hg rebase" of the revision removing largefiles, "hg status" may still show ""R" for such largefiles unexpectedly. "lfilesrepo.commit" executes the special code path for automated committing while rebase/transplant, and lfdirstate entries for removed files aren't updated in this code path, even after successful committing. Then, "R" entries still existing in lfdirstate cause unexpected "hg status" output. This patch synchronizes lfdirstate with dirstate after automated committing. This patch passes False as "normallookup" to "synclfdirstate", because modified files in "files()" of the recent (= just committed) context should be "normal"-ed. 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. Hooking "markcommitted" of ctx in "localrepository.commitctx" may achieve this. This problem occurs, only when (1) the parent of the working directory is rebased and (2) it removes largefiles, because: - if the parent of the working directory isn't rebased, returning to the initial revision (= update) after rebase hides this problem - files added on "other" branch (= rebase target) are treated not as "added" but as "modified" (= "normal" status and "unset" timestamp) at merging This patch tests also the status of added largefile, but it is only for avoiding regression. In addition to conditions above, "hg status" must not take existing files to reproduce this problem, because existing files make "match._files" not empty in "lfilesrepo.status" code path below: def sfindirstate(f): sf = lfutil.standin(f) dirstate = self.dirstate return sf in dirstate or sf in dirstate.dirs() match._files = [f for f in match._files if sfindirstate(f)] Not empty "match._files" prevents "status" on lfdirstate from returning the result containing problematic "R" files. This is reason why "large1" (removed) and "largeX" (added) are checked separately in this patch. Problematic code path in "lfilesrepo.commit" is used also by "hg transplant", but this problem doesn't occur at "hg transplant", because invocation of "updatelfiles" after transplant-ing in "overridetransplant" causes cleaning lfdirstate up. This patch tests also "hg transplant" as same as "hg rebase", but it is only for avoiding regression.
2014-08-11 17:29:43 +04:00
$ hg status -A largeX
C largeX
$ hg strip -q 5
largefiles: add test for large/normal conflict at linear merging Before this patch, there is no explicit test for it: test-issue3084.t seems to test such conflict only at branch merging. This patch uses "[debug] dirstate.delaywrite" feature for the tests expecting "M" status of largefiles, to confirm certainly whether files are marked unexpectedly as "clean".
2014-08-15 15:28:51 +04:00
Test that linear merge can detect modification (and conflict) correctly
(linear merge without conflict)
$ echo 'large2 for linear merge (no conflict)' > large2
$ hg update 3 --config debug.dirstate.delaywrite=2
getting changed largefiles
1 largefiles updated, 0 removed
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg status -A large2
M large2
$ cat large2
large2 for linear merge (no conflict)
$ cat .hglf/large2
9c4bf8f1b33536d6e5f89447e10620cfe52ea710
(linear merge with conflict, choosing "other")
$ hg update -q -C 2
$ echo 'large1 for linear merge (conflict)' > large1
$ hg update 3 --config ui.interactive=True <<EOF
> o
> EOF
largefile large1 has a merge conflict
ancestor was 4669e532d5b2c093a78eca010077e708a071bb64
keep (l)ocal ba94c2efe5b7c5e0af8d189295ce00553b0612b7 or
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
take (o)ther e5bb990443d6a92aaf7223813720f7566c9dd05b? o
getting changed largefiles
largefiles: add test for large/normal conflict at linear merging Before this patch, there is no explicit test for it: test-issue3084.t seems to test such conflict only at branch merging. This patch uses "[debug] dirstate.delaywrite" feature for the tests expecting "M" status of largefiles, to confirm certainly whether files are marked unexpectedly as "clean".
2014-08-15 15:28:51 +04:00
1 largefiles updated, 0 removed
1 files updated, 1 files merged, 0 files removed, 0 files unresolved
$ hg status -A large1
C large1
$ cat large1
large1 in #3
$ cat .hglf/large1
e5bb990443d6a92aaf7223813720f7566c9dd05b
(linear merge with conflict, choosing "local")
$ hg update -q -C 2
$ echo 'large1 for linear merge (conflict)' > large1
$ hg update 3 --config debug.dirstate.delaywrite=2
largefile large1 has a merge conflict
ancestor was 4669e532d5b2c093a78eca010077e708a071bb64
keep (l)ocal ba94c2efe5b7c5e0af8d189295ce00553b0612b7 or
take (o)ther e5bb990443d6a92aaf7223813720f7566c9dd05b? l
1 files updated, 1 files merged, 0 files removed, 0 files unresolved
$ hg status -A large1
M large1
$ cat large1
large1 for linear merge (conflict)
$ cat .hglf/large1
ba94c2efe5b7c5e0af8d189295ce00553b0612b7
largefiles: keep largefiles from colliding with normal one during linear merge Before this patch, linear merging of modified or newly added largefile causes unexpected result, if (1) largefile collides with same name normal one in the target revision and (2) "local" largefile is chosen, even though branch merging between such revisions doesn't. Expected result of such linear merging is: (1) (not yet recorded) largefile is kept in the working directory (2) largefile is marked as (re-)"added" (3) colliding normal file is marked as "removed" But actual result is: (1) largefile in the working directory is unlinked (2) largefile is marked as "normal" (so treated as "missing") (3) the dirstate entry for colliding normal file is just dropped (1) is very serious, because there is no way to restore temporarily modified largefiles. (3) prevents the next commit from adding the manifest with correct "removal of (normal) file" information for newly created changeset. The root cause of this problem is putting "lfile" into "actions['r']" in linear-merging case. At liner merging, "actions['r']" causes: - unlinking "target file" in the working directory, but "lfile" as "target file" is also largefile itself in this case - dropping the dirstate entry for target file "actions['f']" (= "forget") does only the latter, and this is reason why this patch doesn't choose putting "lfile" into it instead of "actions['r']". This patch newly introduces action "lfmr" (LargeFiles: Mark as Removed) to mark colliding normal file as "removed" without unlinking it. This patch uses "hg debugdirstate" instead of "hg status" in test, because: - choosing "local largefile" hides "removed" status of "remote normal file" in "hg status" output, and - "hg status" for "large2" in this case has another problem fixed in the subsequent patch
2014-08-15 15:28:51 +04:00
Test a linear merge to a revision containing same-name normal file
$ hg update -q -C 3
$ hg remove large2
$ echo 'large2 as normal file' > large2
$ hg add large2
$ echo 'large3 as normal file' > large3
$ hg add large3
$ hg commit -m '#5'
$ hg manifest
.hglf/large1
large2
large3
normal1
(modified largefile is already switched to normal)
$ hg update -q -C 2
$ echo 'modified large2 for linear merge' > large2
$ hg update -q 5
remote turned local largefile large2 into a normal file
keep (l)argefile or use (n)ormal file? l
$ hg debugdirstate --nodates | grep large2
debugdirstate: don't hide date field with --nodate, just show 'set'/'unset' The value of the dirstate date field cannot be used in tests and we thus have to use debugdirstate with --nodate. It is however still very helpful to be able to see whether the date field has been set or still is unset. The absence of that information made it hard to debug some largefile dirstate issues. This change _could_ make the test suite more unstable ... but that would be places where the test suite or the code should be made more stable. (Note: 'unset' with the magic negative sizes is reliable. 'unset' for normal sizes would probably not be reliable, but there is no such occurrences in the test suite and it should thus be reliable.) This output wastes more horizontal space in the --nodate output, but it also makes things simpler that the output format always is the same. It is just a debug command so let's keep it simple.
2015-01-09 20:38:02 +03:00
a 0 -1 unset .hglf/large2
r 0 0 set large2
largefiles: update lfdirstate for unchanged largefiles during linear merging Before this patch, linear merging of modified largefiles causes an unexpected result, if (1) largefile collides with same-name normal one in the target revision and (2) "local" largefile is chosen, even though branch merging between such revisions works correctly. Expected result of such linear merging is marking the largefile as (re-)"added", but the actual result is marking it as "modified". The standin of modified "local largefile" is not changed by linear merging, and updating/merging update lfdirstate entries only for largefiles of which standins are changed. This patch adds the code path to update lfdirstate only for largefiles of which standins are not changed. In this case, "synclfdirstate" should be invoked with True as "normallookup" argument always to force using "normallookup" on dirstate for "n" files, because "normal" may mark target files as "clean" unexpectedly. To reduce cost of "lfile not in filelist", this patch converts "filelist" to a "set" object: "filelist" is used only in (1) the newly added code path and (2) the next line of "filelist = set(filelist)". 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 during "merge.update" execution: maybe by hooking "recordupdates" (+ total refactoring around lfdirstate handling)
2014-08-15 15:28:51 +04:00
$ hg status -A large2
A large2
largefiles: keep largefiles from colliding with normal one during linear merge Before this patch, linear merging of modified or newly added largefile causes unexpected result, if (1) largefile collides with same name normal one in the target revision and (2) "local" largefile is chosen, even though branch merging between such revisions doesn't. Expected result of such linear merging is: (1) (not yet recorded) largefile is kept in the working directory (2) largefile is marked as (re-)"added" (3) colliding normal file is marked as "removed" But actual result is: (1) largefile in the working directory is unlinked (2) largefile is marked as "normal" (so treated as "missing") (3) the dirstate entry for colliding normal file is just dropped (1) is very serious, because there is no way to restore temporarily modified largefiles. (3) prevents the next commit from adding the manifest with correct "removal of (normal) file" information for newly created changeset. The root cause of this problem is putting "lfile" into "actions['r']" in linear-merging case. At liner merging, "actions['r']" causes: - unlinking "target file" in the working directory, but "lfile" as "target file" is also largefile itself in this case - dropping the dirstate entry for target file "actions['f']" (= "forget") does only the latter, and this is reason why this patch doesn't choose putting "lfile" into it instead of "actions['r']". This patch newly introduces action "lfmr" (LargeFiles: Mark as Removed) to mark colliding normal file as "removed" without unlinking it. This patch uses "hg debugdirstate" instead of "hg status" in test, because: - choosing "local largefile" hides "removed" status of "remote normal file" in "hg status" output, and - "hg status" for "large2" in this case has another problem fixed in the subsequent patch
2014-08-15 15:28:51 +04:00
$ cat large2
modified large2 for linear merge
(added largefile is already committed as normal)
$ hg update -q -C 2
$ echo 'large3 as large file for linear merge' > large3
$ hg add --large large3
$ hg update -q 5
remote turned local largefile large3 into a normal file
keep (l)argefile or use (n)ormal file? l
$ hg debugdirstate --nodates | grep large3
debugdirstate: don't hide date field with --nodate, just show 'set'/'unset' The value of the dirstate date field cannot be used in tests and we thus have to use debugdirstate with --nodate. It is however still very helpful to be able to see whether the date field has been set or still is unset. The absence of that information made it hard to debug some largefile dirstate issues. This change _could_ make the test suite more unstable ... but that would be places where the test suite or the code should be made more stable. (Note: 'unset' with the magic negative sizes is reliable. 'unset' for normal sizes would probably not be reliable, but there is no such occurrences in the test suite and it should thus be reliable.) This output wastes more horizontal space in the --nodate output, but it also makes things simpler that the output format always is the same. It is just a debug command so let's keep it simple.
2015-01-09 20:38:02 +03:00
a 0 -1 unset .hglf/large3
r 0 0 set large3
largefiles: update lfdirstate for unchanged largefiles during linear merging Before this patch, linear merging of modified largefiles causes an unexpected result, if (1) largefile collides with same-name normal one in the target revision and (2) "local" largefile is chosen, even though branch merging between such revisions works correctly. Expected result of such linear merging is marking the largefile as (re-)"added", but the actual result is marking it as "modified". The standin of modified "local largefile" is not changed by linear merging, and updating/merging update lfdirstate entries only for largefiles of which standins are changed. This patch adds the code path to update lfdirstate only for largefiles of which standins are not changed. In this case, "synclfdirstate" should be invoked with True as "normallookup" argument always to force using "normallookup" on dirstate for "n" files, because "normal" may mark target files as "clean" unexpectedly. To reduce cost of "lfile not in filelist", this patch converts "filelist" to a "set" object: "filelist" is used only in (1) the newly added code path and (2) the next line of "filelist = set(filelist)". 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 during "merge.update" execution: maybe by hooking "recordupdates" (+ total refactoring around lfdirstate handling)
2014-08-15 15:28:51 +04:00
$ hg status -A large3
A large3
largefiles: keep largefiles from colliding with normal one during linear merge Before this patch, linear merging of modified or newly added largefile causes unexpected result, if (1) largefile collides with same name normal one in the target revision and (2) "local" largefile is chosen, even though branch merging between such revisions doesn't. Expected result of such linear merging is: (1) (not yet recorded) largefile is kept in the working directory (2) largefile is marked as (re-)"added" (3) colliding normal file is marked as "removed" But actual result is: (1) largefile in the working directory is unlinked (2) largefile is marked as "normal" (so treated as "missing") (3) the dirstate entry for colliding normal file is just dropped (1) is very serious, because there is no way to restore temporarily modified largefiles. (3) prevents the next commit from adding the manifest with correct "removal of (normal) file" information for newly created changeset. The root cause of this problem is putting "lfile" into "actions['r']" in linear-merging case. At liner merging, "actions['r']" causes: - unlinking "target file" in the working directory, but "lfile" as "target file" is also largefile itself in this case - dropping the dirstate entry for target file "actions['f']" (= "forget") does only the latter, and this is reason why this patch doesn't choose putting "lfile" into it instead of "actions['r']". This patch newly introduces action "lfmr" (LargeFiles: Mark as Removed) to mark colliding normal file as "removed" without unlinking it. This patch uses "hg debugdirstate" instead of "hg status" in test, because: - choosing "local largefile" hides "removed" status of "remote normal file" in "hg status" output, and - "hg status" for "large2" in this case has another problem fixed in the subsequent patch
2014-08-15 15:28:51 +04:00
$ cat large3
large3 as large file for linear 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.
2014-08-24 18:47:26 +04:00
$ rm -f large3 .hglf/large3
Test that the internal linear merging works correctly
(both heads are stripped to keep pairing of revision number and commit log)
$ hg update -q -C 2
$ hg strip 3 4
bundles: do not overwrite existing backup bundles (BC) Previously, a backup bundle could overwrite an existing bundle and cause user data loss. For instance, if you have A<-B<-C and strip B, it produces backup bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it overwrites the existing B-backup.hg and C is lost. The fix is to add a hash of all the nodes inside that bundle to the filename. Fixed up existing tests and added a new test in test-strip.t
2015-01-09 21:52:14 +03:00
saved backup bundle to $TESTTMP/repo/.hg/strip-backup/9530e27857f7-2e7b195d-backup.hg (glob)
$ mv .hg/strip-backup/9530e27857f7-2e7b195d-backup.hg $TESTTMP
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.
2014-08-24 18:47:26 +04:00
(internal linear merging at "hg pull --update")
$ echo 'large1 for linear merge (conflict)' > large1
$ echo 'large2 for linear merge (conflict with normal file)' > large2
bundles: do not overwrite existing backup bundles (BC) Previously, a backup bundle could overwrite an existing bundle and cause user data loss. For instance, if you have A<-B<-C and strip B, it produces backup bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it overwrites the existing B-backup.hg and C is lost. The fix is to add a hash of all the nodes inside that bundle to the filename. Fixed up existing tests and added a new test in test-strip.t
2015-01-09 21:52:14 +03:00
$ hg pull --update --config debug.dirstate.delaywrite=2 $TESTTMP/9530e27857f7-2e7b195d-backup.hg
pulling from $TESTTMP/9530e27857f7-2e7b195d-backup.hg (glob)
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.
2014-08-24 18:47:26 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 5 changes to 5 files
remote turned local largefile large2 into a normal file
keep (l)argefile or use (n)ormal file? l
largefile large1 has a merge conflict
ancestor was 4669e532d5b2c093a78eca010077e708a071bb64
keep (l)ocal ba94c2efe5b7c5e0af8d189295ce00553b0612b7 or
take (o)ther e5bb990443d6a92aaf7223813720f7566c9dd05b? l
2 files updated, 1 files merged, 0 files removed, 0 files unresolved
$ hg status -A large1
M large1
$ cat large1
large1 for linear merge (conflict)
$ cat .hglf/large1
ba94c2efe5b7c5e0af8d189295ce00553b0612b7
$ hg status -A large2
A large2
$ cat large2
large2 for linear merge (conflict with normal file)
$ cat .hglf/large2
d7591fe9be0f6227d90bddf3e4f52ff41fc1f544
(internal linear merging at "hg unbundle --update")
$ hg update -q -C 2
$ hg rollback -q
$ echo 'large1 for linear merge (conflict)' > large1
$ echo 'large2 for linear merge (conflict with normal file)' > large2
bundles: do not overwrite existing backup bundles (BC) Previously, a backup bundle could overwrite an existing bundle and cause user data loss. For instance, if you have A<-B<-C and strip B, it produces backup bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it overwrites the existing B-backup.hg and C is lost. The fix is to add a hash of all the nodes inside that bundle to the filename. Fixed up existing tests and added a new test in test-strip.t
2015-01-09 21:52:14 +03:00
$ hg unbundle --update --config debug.dirstate.delaywrite=2 $TESTTMP/9530e27857f7-2e7b195d-backup.hg
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.
2014-08-24 18:47:26 +04:00
adding changesets
adding manifests
adding file changes
added 3 changesets with 5 changes to 5 files
remote turned local largefile large2 into a normal file
keep (l)argefile or use (n)ormal file? l
largefile large1 has a merge conflict
ancestor was 4669e532d5b2c093a78eca010077e708a071bb64
keep (l)ocal ba94c2efe5b7c5e0af8d189295ce00553b0612b7 or
take (o)ther e5bb990443d6a92aaf7223813720f7566c9dd05b? l
2 files updated, 1 files merged, 0 files removed, 0 files unresolved
$ hg status -A large1
M large1
$ cat large1
large1 for linear merge (conflict)
$ cat .hglf/large1
ba94c2efe5b7c5e0af8d189295ce00553b0612b7
$ hg status -A large2
A large2
$ cat large2
large2 for linear merge (conflict with normal file)
$ cat .hglf/large2
d7591fe9be0f6227d90bddf3e4f52ff41fc1f544
(internal linear merging in subrepo at "hg update")
$ cd ..
$ hg init subparent
$ cd subparent
$ hg clone -q -u 2 ../repo sub
$ cat > .hgsub <<EOF
> sub = sub
> EOF
$ hg add .hgsub
$ hg commit -m '#0@parent'
$ cat .hgsubstate
f74e50bd9e5594b7cf1e6c5cbab86ddd25f3ca2f sub
$ hg -R sub update -q
$ hg commit -m '#1@parent'
$ cat .hgsubstate
d65e59e952a9638e2ce863b41a420ca723dd3e8d sub
$ hg update -q 0
$ echo 'large1 for linear merge (conflict)' > sub/large1
$ echo 'large2 for linear merge (conflict with normal file)' > sub/large2
$ hg update --config ui.interactive=True --config debug.dirstate.delaywrite=2 <<EOF
> m
> r
> l
> l
> EOF
subrepository sub diverged (local revision: f74e50bd9e55, remote revision: d65e59e952a9)
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
(M)erge, keep (l)ocal or keep (r)emote? m
subrepository sources for sub differ (in checked out version)
subrepo: remove superfluous newline from subrepo prompt
2014-10-01 03:08:17 +04:00
use (l)ocal source (f74e50bd9e55) or (r)emote source (d65e59e952a9)? r
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
remote turned local largefile large2 into a normal file
keep (l)argefile or use (n)ormal file? l
largefile large1 has a merge conflict
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.
2014-08-24 18:47:26 +04:00
ancestor was 4669e532d5b2c093a78eca010077e708a071bb64
keep (l)ocal ba94c2efe5b7c5e0af8d189295ce00553b0612b7 or
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
take (o)ther e5bb990443d6a92aaf7223813720f7566c9dd05b? l
2 files updated, 1 files merged, 0 files removed, 0 files unresolved
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.
2014-08-24 18:47:26 +04:00
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg -R sub status -A sub/large1
M sub/large1
$ cat sub/large1
large1 for linear merge (conflict)
$ cat sub/.hglf/large1
ba94c2efe5b7c5e0af8d189295ce00553b0612b7
$ hg -R sub status -A sub/large2
A sub/large2
$ cat sub/large2
large2 for linear merge (conflict with normal file)
$ cat sub/.hglf/large2
d7591fe9be0f6227d90bddf3e4f52ff41fc1f544
largefiles: keep largefiles from colliding with normal one during linear merge Before this patch, linear merging of modified or newly added largefile causes unexpected result, if (1) largefile collides with same name normal one in the target revision and (2) "local" largefile is chosen, even though branch merging between such revisions doesn't. Expected result of such linear merging is: (1) (not yet recorded) largefile is kept in the working directory (2) largefile is marked as (re-)"added" (3) colliding normal file is marked as "removed" But actual result is: (1) largefile in the working directory is unlinked (2) largefile is marked as "normal" (so treated as "missing") (3) the dirstate entry for colliding normal file is just dropped (1) is very serious, because there is no way to restore temporarily modified largefiles. (3) prevents the next commit from adding the manifest with correct "removal of (normal) file" information for newly created changeset. The root cause of this problem is putting "lfile" into "actions['r']" in linear-merging case. At liner merging, "actions['r']" causes: - unlinking "target file" in the working directory, but "lfile" as "target file" is also largefile itself in this case - dropping the dirstate entry for target file "actions['f']" (= "forget") does only the latter, and this is reason why this patch doesn't choose putting "lfile" into it instead of "actions['r']". This patch newly introduces action "lfmr" (LargeFiles: Mark as Removed) to mark colliding normal file as "removed" without unlinking it. This patch uses "hg debugdirstate" instead of "hg status" in test, because: - choosing "local largefile" hides "removed" status of "remote normal file" in "hg status" output, and - "hg status" for "large2" in this case has another problem fixed in the subsequent patch
2014-08-15 15:28:51 +04:00
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).
2014-07-22 18:59:34 +04:00
$ cd ..
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".
2014-08-24 18:47:26 +04:00
$ cd repo
Test that rebase updates largefiles in the working directory even if
it is aborted by conflict.
$ hg update -q -C 3
$ cat .hglf/large1
e5bb990443d6a92aaf7223813720f7566c9dd05b
$ cat large1
large1 in #3
$ hg rebase -s 1 -d 3 --keep --config ui.interactive=True <<EOF
> o
> EOF
rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
2014-12-09 05:45:26 +03:00
rebasing 1:72518492caa6 "#1"
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".
2014-08-24 18:47:26 +04:00
largefile large1 has a merge conflict
ancestor was 4669e532d5b2c093a78eca010077e708a071bb64
keep (l)ocal e5bb990443d6a92aaf7223813720f7566c9dd05b or
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
take (o)ther 58e24f733a964da346e2407a2bee99d9001184f5? o
merging normal1
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".
2014-08-24 18:47:26 +04:00
warning: conflicts during merge.
merging normal1 incomplete! (edit conflicts, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
[1]
$ cat .hglf/large1
58e24f733a964da346e2407a2bee99d9001184f5
$ cat large1
large1 in #1
largefiles: update standins only at the 1st commit of "hg rebase --continue" Before this patch, "hg rebase --continue" may record incorrect standins, because largefiles extension always avoid updating standins while rebasing, even though largefiles in the working directory may be modified manually at the 1st commit of "hg rebase --continue". But, on the other hand, updating standins should be avoided at subsequent commits for efficiency reason. To update standins only at the 1st commit of "hg rebase --continue", this patch introduces state-full callable object "automatedcommithook", which updates standins by "lfutil.updatestandinsbymatch()" only at the 1st commit of resuming. Even after this patch, "repo._isrebasing = True" is still needed to avoid some status report while updating largefiles in "lfcommands.updatelfiles()". This is reason why this patch omits not "repo._isrebasing = True" in "overriderebase" but examination of "getattr(repo, "_isrebasing", False)" in "updatestandinsbymatch".
2014-11-05 17:24:47 +03:00
Test that rebase updates standins for manually modified largefiles at
the 1st commit of resuming.
$ echo "manually modified before 'hg rebase --continue'" > large1
$ hg resolve -m normal1
(no more unresolved files)
$ hg rebase --continue --config ui.interactive=True <<EOF
> c
> EOF
rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
2014-12-09 05:45:26 +03:00
rebasing 1:72518492caa6 "#1"
rebasing 4:07d6153b5c04 "#4"
largefiles: update standins only at the 1st commit of "hg rebase --continue" Before this patch, "hg rebase --continue" may record incorrect standins, because largefiles extension always avoid updating standins while rebasing, even though largefiles in the working directory may be modified manually at the 1st commit of "hg rebase --continue". But, on the other hand, updating standins should be avoided at subsequent commits for efficiency reason. To update standins only at the 1st commit of "hg rebase --continue", this patch introduces state-full callable object "automatedcommithook", which updates standins by "lfutil.updatestandinsbymatch()" only at the 1st commit of resuming. Even after this patch, "repo._isrebasing = True" is still needed to avoid some status report while updating largefiles in "lfcommands.updatelfiles()". This is reason why this patch omits not "repo._isrebasing = True" in "overriderebase" but examination of "getattr(repo, "_isrebasing", False)" in "updatestandinsbymatch".
2014-11-05 17:24:47 +03:00
local changed .hglf/large1 which remote deleted
use (c)hanged version or (d)elete? c
$ hg diff -c "tip~1" --nodates .hglf/large1 | grep '^[+-][0-9a-z]'
-e5bb990443d6a92aaf7223813720f7566c9dd05b
+8a4f783556e7dea21139ca0466eafce954c75c13
$ rm -f large1
$ hg update -q -C tip
$ cat large1
manually modified before 'hg rebase --continue'
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".
2014-08-24 18:47:26 +04:00
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
2014-08-24 18:47:26 +04:00
Test that transplant updates largefiles, of which standins are safely
changed, even if it is aborted by conflict of other.
$ hg update -q -C 5
$ cat .hglf/large1
e5bb990443d6a92aaf7223813720f7566c9dd05b
$ cat large1
large1 in #3
$ hg diff -c 4 .hglf/largeX | grep '^[+-][0-9a-z]'
+fa44618ea25181aff4f48b70428294790cec9f61
$ hg transplant 4
applying 07d6153b5c04
patching file .hglf/large1
Hunk #1 FAILED at 0
1 out of 1 hunks FAILED -- saving rejects to file .hglf/large1.rej
patch failed to apply
abort: fix up the merge and run hg transplant --continue
[255]
$ hg status -A large1
C large1
$ cat .hglf/large1
e5bb990443d6a92aaf7223813720f7566c9dd05b
$ cat large1
large1 in #3
$ hg status -A largeX
A largeX
$ cat .hglf/largeX
fa44618ea25181aff4f48b70428294790cec9f61
$ cat largeX
largeX
largefiles: update standins only at the 1st commit of "transplant --continue" Before this patch, "hg transplant --continue" may record incorrect standins, because largefiles extension always avoid updating standins while transplanting, even though largefiles in the working directory may be modified manually at the 1st commit of "hg transplant --continue". But, on the other hand, updating standins should be avoided at subsequent commits for efficiency reason. To update standins only at the 1st commit of "hg transplant --continue", this patch uses "automatedcommithook", which updates standins by "lfutil.updatestandinsbymatch()" only at the 1st commit of resuming. Even after this patch, "repo._istransplanting = True" is still needed to avoid some status report while updating largefiles in "lfcommands.updatelfiles()". This is reason why this patch omits not "repo._istransplanting = True" in "overriderebase" but examination of "getattr(repo, "_istransplanting", False)" in "updatestandinsbymatch".
2014-11-07 18:48:41 +03:00
Test that transplant updates standins for manually modified largefiles
at the 1st commit of resuming.
$ echo "manually modified before 'hg transplant --continue'" > large1
$ hg transplant --continue
07d6153b5c04 transplanted as f1bf30eb88cc
$ hg diff -c tip .hglf/large1 | grep '^[+-][0-9a-z]'
-e5bb990443d6a92aaf7223813720f7566c9dd05b
+6a4f36d4075fbe0f30ec1d26ca44e63c05903671
$ rm -f large1
$ hg update -q -C tip
$ cat large1
manually modified before 'hg transplant --continue'
largefiles: ignore removal status of files not managed in the target context Before this patch, "hg status --rev REV" listed largefiles removed in the working directory up with "R" mark, even if they aren't managed in the REV. Normal files aren't listed up in such case. When "lfilesrepo.status" is invoked for "hg status --rev REV", it treats files on conditions below as "removed" (to avoid manifest full scan in "ctx.status" ?): - marked as "R" in lfdirstate, or - files managed in the target revision but unknown in the manifest of the working context (= not including "R" files) But the former can include files not managed in the target context. To ignore removal status of files not managed in the target context, this patch drops files unknown in the target revision from "removed" list.
2014-10-27 19:14:11 +03:00
Test that "hg status" doesn't show removal of largefiles not managed
in the target context.
$ hg update -q -C 4
$ hg remove largeX
$ hg status -A largeX
R largeX
$ hg status -A --rev '.^1' largeX
largefiles: add examination of exec bit in "hg status --rev REV" case Before this patch, "hg status --rev REV" doesn't list largefiles up with "M" mark, even if exec bit of them is changed, because "lfilesrepo.status" doesn't examine exec bit in such case.
2014-10-27 19:14:12 +03:00
#if execbit
Test that "hg status" against revisions other than parent notices exec
bit changes of largefiles.
$ hg update -q -C 4
(the case that large2 doesn't have exec bit in the target context but
in the working context)
$ chmod +x large2
$ hg status -A --rev 0 large2
M large2
$ hg commit -m 'chmod +x large2'
(the case that large2 has exec bit in the target context but not in
the working context)
$ echo dummy > dummy
$ hg add dummy
$ hg commit -m 'revision for separation'
$ chmod -x large2
$ hg status -A --rev '.^1' large2
M large2
largefiles: avoid exec-bit examination on the platform being unaware of it Changeset 5b64e22ecd8e introduced the examination of exec bit of largefiles in "hg status --rev REV" case, but it doesn't avoid it on the platform being unaware of exec-bit (e.g. on NTFS of Windows).
2014-11-25 12:37:28 +03:00
#else
Test that "hg status" against revisions other than parent ignores exec
bit correctly on the platform being unaware of it.
$ hg update -q -C 4
$ cat > exec-bit.patch <<EOF
> # HG changeset patch
> # User test
> # Date 0 0
> # Thu Jan 01 00:00:00 1970 +0000
> # Node ID be1b433a65b12b27b5519d92213e14f7e1769b90
> # Parent 07d6153b5c04313efb75deec9ba577de7faeb727
> chmod +x large2
>
> diff --git a/.hglf/large2 b/.hglf/large2
> old mode 100644
> new mode 100755
> EOF
$ hg import --exact --bypass exec-bit.patch
applying exec-bit.patch
$ hg status -A --rev tip large2
C large2
largefiles: add examination of exec bit in "hg status --rev REV" case Before this patch, "hg status --rev REV" doesn't list largefiles up with "M" mark, even if exec bit of them is changed, because "lfilesrepo.status" doesn't examine exec bit in such case.
2014-10-27 19:14:12 +03:00
#endif
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".
2014-08-24 18:47:26 +04:00
$ cd ..
largefiles: move "copyalltostore" invocation into "markcommitted" Before this patch, while "hg convert", largefiles avoids copying largefiles in the working directory into the store area by combination of setting "repo._isconverting" in "mercurialsink{before|after}" and checking it in "copytostoreabsolute". This avoiding is needed while "hg convert", because converting doesn't update largefiles in the working directory. But this implementation is not efficient, because: - invocation in "markcommitted" can easily ensure updating largefiles in the working directory "markcommitted" is invoked only when new revision is committed via "commit" of "localrepository" (= with files in the working directory). On the other hand, "commitctx" may be invoked directly for in-memory committing. - committing without updating the working directory (e.g. "import --bypass") also needs this kind of avoiding For efficiency of this kind of avoiding, this patch does: - move "copyalltostore" invocation into "markcommitted" - remove meaningless procedures below: - hooking "mercurialsink{before|after}" to (un)set "repo._isconverting" - checking "repo._isconverting" in "copytostoreabsolute" This patch invokes "copyalltostore" also in "_commitcontext", because "_commitcontext" expects that largefiles in the working directory are copied into store area after "commitctx". In this case, the working directory is used as a kind of temporary area to write largefiles out, even though converted revisions are committed via "commitctx" (without updating normal files).
2014-11-07 18:48:41 +03:00
Test that "hg convert" avoids copying largefiles from the working
directory into store, because "hg convert" doesn't update largefiles
in the working directory (removing files under ".cache/largefiles"
forces "hg convert" to copy corresponding largefiles)
$ cat >> $HGRCPATH <<EOF
> [extensions]
> convert =
> EOF
$ rm $TESTTMP/.cache/largefiles/6a4f36d4075fbe0f30ec1d26ca44e63c05903671
$ hg convert -q repo repo.converted
Reference in New Issue Copy Permalink