facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-10 00:45:18 +03:00
Code Issues Projects Releases Wiki Activity
c82190e72c
sapling/tests/test-issue3084.t

370 lines
10 KiB
Perl
Raw Normal View History

largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
$ echo "[extensions]" >> $HGRCPATH
$ echo "largefiles =" >> $HGRCPATH
Create the repository outside $HOME since largefiles write to
$HOME/.cache/largefiles.
$ hg init test
$ cd test
$ echo "root" > root
$ hg add root
$ hg commit -m "Root commit"
$ echo "large" > foo
$ hg add --large foo
$ hg commit -m "Add foo as a largefile"
$ hg update -r 0
getting changed largefiles
0 largefiles updated, 1 removed
largefiles: fix largefiles+subrepo update (issue3752) Override updaterepo() instead of individual methods that may not be called for each subrepo. Add test. Based on patch from Matt Harbison. Changes the order of update-related messages (now largefiles comes before the global status).
2013-01-23 03:51:53 +04:00
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
$ echo "normal" > foo
$ hg add foo
$ hg commit -m "Add foo as normal file"
created new head
Normal file in the working copy, keeping the normal version:
$ echo "n" | hg merge --config ui.interactive=Yes
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local normal file foo into a largefile
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
use (l)argefile or keep (n)ormal file? getting changed largefiles
largefiles: getstandinmatcher should not depend on existence of directories Looking for a (potentially empty) directory was not reliable - both because it is a reasonable assumption that empty directories can be removed and because it wasn't created in all cases ... such as when pulling to an existing repository.
2013-02-28 16:45:18 +04:00
0 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, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
$ hg status
$ cat foo
normal
Normal file in the working copy, keeping the largefile version:
$ hg update -q -C
$ echo "l" | hg merge --config ui.interactive=Yes
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local normal file foo into a largefile
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
use (l)argefile or keep (n)ormal file? getting changed largefiles
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
$ hg status
M foo
$ hg diff --nodates
diff -r fa129ab6b5a7 .hglf/foo
--- /dev/null
+++ b/.hglf/foo
@@ -0,0 +1,1 @@
+7f7097b041ccf68cc5561e9600da4655d21c6d18
diff -r fa129ab6b5a7 foo
--- a/foo
+++ /dev/null
@@ -1,1 +0,0 @@
-normal
$ cat foo
large
Largefile in the working copy, keeping the normal version:
$ hg update -q -C -r 1
$ echo "n" | hg merge --config ui.interactive=Yes
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local largefile foo into a normal file
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
keep (l)argefile or use (n)ormal file? getting changed largefiles
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
0 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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
$ hg status
M foo
$ hg diff --nodates
diff -r ff521236428a .hglf/foo
--- a/.hglf/foo
+++ /dev/null
@@ -1,1 +0,0 @@
-7f7097b041ccf68cc5561e9600da4655d21c6d18
diff -r ff521236428a foo
--- /dev/null
+++ b/foo
@@ -0,0 +1,1 @@
+normal
$ cat foo
normal
Largefile in the working copy, keeping the largefile version:
$ hg update -q -C -r 1
$ echo "l" | hg merge --config ui.interactive=Yes
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local largefile foo into a normal file
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
keep (l)argefile or use (n)ormal file? getting changed largefiles
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
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, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: handle merges between normal files and largefiles (issue3084) The largefiles extension prevents users from adding a normal file named 'foo' if there is already a largefile with the same name. However, there was a loop-hole: when merging, it was possible to bring in a normal file named 'foo' while also having a '.hglf/foo' file. This patch fixes this by extending the manifest merge to deal with these kinds of conflicts. If there is a normal file 'foo' in the working copy, and the other parent brings in a '.hglf/foo' file, then the user will be prompted to keep the normal file or the largefile. Likewise for the symmetric case where a normal file is brought in via the second parent. The prompt looks like this: $ hg merge foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? After the merge, either the '.hglf/foo' file or the 'foo' file will have been deleted. This would cause status to return output like: $ hg status M foo R foo To fix this, the lfiles_repo.status method is changed so that a removed normal file isn't shown if there is largefile with the same name, and vice versa for largefiles.
2011-12-09 20:35:00 +04:00
$ hg status
$ cat foo
large
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
largefiles: don't prompt for normal/largefile changes when doing plain updates We used to get like: $ hg up -r 2 foo has been turned into a normal file keep as (l)argefile or use (n)ormal file? l getting changed largefiles 0 largefiles updated, 0 removed 0 files updated, 0 files merged, 2 files removed, 0 files unresolved $ cat foo cat: foo: No such file or directory [1] - which both asked the wrong question and did the wrong thing. Instead, skip this conflict resolution when the local conflicting file has been scheduled for removal and there thus is no conflict.
2013-10-24 22:33:59 +04:00
Whatever ... commit something so we can invoke merge when updating
$ hg commit -m '3: Merge'
Updating from largefile to normal - no reason to prompt
$ hg up -r 2
getting changed largefiles
0 largefiles updated, 0 removed
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ cat foo
normal
(the update above used to leave the working dir in a very weird state - clean it
$ hg up -qr null
$ hg up -qr 2
)
Updating from normal to largefile - no reason to prompt
$ hg up -r 3
getting changed largefiles
1 largefiles updated, 0 removed
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ cat foo
large
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
$ cd ..
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
Systematic testing of merges involving largefiles:
Ancestor: normal Parent: normal= Parent: large result: large
Ancestor: normal Parent: normal2 Parent: large result: ?
Ancestor: large Parent: large= Parent: normal result: normal
Ancestor: large Parent: large2 Parent: normal result: ?
All cases should try merging both ways.
"=" means same file content.
Prepare test repo:
$ hg init merges
$ cd merges
$ touch f1
largefiles: avoid unnecessary creation of .hg/largefiles when opening lfdirstate Previously, the directory '.hg/largefiles' would always be created if it didn't exist when the lfdirstate was opened. If there were no standin files, no dirstate file would be created in the directory. The end result was that enabling the largefiles extension globally, but not explicitly adding a largefile would result in the repository eventually sprouting this directory. Creation of this directory effectively changes readonly operations like summary and status into operations that require write access. Without write access, commands that would succeed without the extension loaded would abort with a surprising error when the extension is loaded, but not actively used: $ hg sum -R /tmp/thg --config extensions.largefiles= parent: 16541:00dc703d5aed repowidget: specify incoming bundle by plain file path to avoid url parsing branch: default abort: Permission denied: '/tmp/thg/.hg/largefiles' This change is simpler than changing the callers of openlfdirstate() to use the 'create' parameter that was introduced in 74522122b97d, and probably how that should have been implemented in the first place.
2014-07-18 04:17:17 +04:00
$ hg ci -Aqm "0-root" --config extensions.largefiles=!
Ensure that .hg/largefiles isn't created before largefiles are added
#if unix-permissions
$ chmod 555 .hg
#endif
$ hg status
#if unix-permissions
$ chmod 755 .hg
#endif
tests: cat error messages are different on Solaris
2014-07-21 22:27:24 +04:00
$ test -f .hg/largefiles
largefiles: avoid unnecessary creation of .hg/largefiles when opening lfdirstate Previously, the directory '.hg/largefiles' would always be created if it didn't exist when the lfdirstate was opened. If there were no standin files, no dirstate file would be created in the directory. The end result was that enabling the largefiles extension globally, but not explicitly adding a largefile would result in the repository eventually sprouting this directory. Creation of this directory effectively changes readonly operations like summary and status into operations that require write access. Without write access, commands that would succeed without the extension loaded would abort with a surprising error when the extension is loaded, but not actively used: $ hg sum -R /tmp/thg --config extensions.largefiles= parent: 16541:00dc703d5aed repowidget: specify incoming bundle by plain file path to avoid url parsing branch: default abort: Permission denied: '/tmp/thg/.hg/largefiles' This change is simpler than changing the callers of openlfdirstate() to use the 'create' parameter that was introduced in 74522122b97d, and probably how that should have been implemented in the first place.
2014-07-18 04:17:17 +04:00
[1]
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
ancestor is "normal":
$ echo normal > f
$ hg ci -Aqm "1-normal-ancestor"
$ touch f2
$ hg ci -Aqm "2-normal-unchanged"
$ hg tag -l "normal="
$ echo normal2 > f
$ hg ci -m "3-normal2"
$ hg tag -l "normal2"
$ hg up -qr 1
$ hg rm f
$ echo large > f
$ hg add --large f
$ hg ci -qm "4-normal-to-large"
$ hg tag -l "large"
$ hg up -qr null
ancestor is "large":
$ echo large > f
$ hg add --large f
$ hg ci -qm "5-large-ancestor"
$ touch f2
$ hg ci -Aqm "6-large-unchanged"
$ hg tag -l "large="
$ echo large2 > f
$ hg ci -m "7-large2"
$ hg tag -l "large2"
$ hg up -qr 5
$ hg rm f
$ echo normal > f
$ hg ci -qAm "8-large-to-normal"
$ hg tag -l "normal"
Ancestor: normal Parent: normal= Parent: large result: large
$ hg up -Cqr normal=
$ hg merge -r large
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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large
swap
$ hg up -Cqr large
$ hg merge -r normal=
getting changed largefiles
0 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
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large
Ancestor: normal Parent: normal2 Parent: large result: ?
(annoying extra prompt ... but it do not do any serious harm)
$ hg up -Cqr normal2
$ hg merge -r large
local changed f which remote deleted
use (c)hanged version or (d)elete? c
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local normal file f into a largefile
use (l)argefile or keep (n)ormal file? l
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large
$ hg up -Cqr normal2
$ ( echo c; echo n ) | hg merge -r large --config ui.interactive=Yes
local changed f which remote deleted
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
use (c)hanged version or (d)elete? remote turned local normal file f into a largefile
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
use (l)argefile or keep (n)ormal file? getting changed largefiles
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
0 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, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
normal2
$ hg up -Cqr normal2
$ echo d | hg merge -r large --config ui.interactive=Yes
local changed f which remote deleted
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
use (c)hanged version or (d)elete? getting changed largefiles
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large
swap
$ hg up -Cqr large
$ hg merge -r normal2
remote changed f which local deleted
use (c)hanged version or leave (d)eleted? c
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local largefile f into a normal file
keep (l)argefile or use (n)ormal file? l
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large
$ hg up -Cqr large
$ ( echo c; echo n ) | hg merge -r normal2 --config ui.interactive=Yes
remote changed f which local deleted
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
use (c)hanged version or leave (d)eleted? remote turned local largefile f into a normal file
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
keep (l)argefile or use (n)ormal file? getting changed largefiles
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
0 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, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
normal2
$ hg up -Cqr large
$ echo d | hg merge -r normal2 --config ui.interactive=Yes
remote changed f which local deleted
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
use (c)hanged version or leave (d)eleted? getting changed largefiles
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
0 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
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large
Ancestor: large Parent: large= Parent: normal result: normal
$ hg up -Cqr large=
$ hg merge -r normal
getting changed largefiles
0 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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
normal
swap
$ hg up -Cqr normal
$ hg merge -r large=
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ cat f
normal
Ancestor: large Parent: large2 Parent: normal result: ?
(annoying extra prompt ... but it do not do any serious harm)
$ hg up -Cqr large2
$ hg merge -r normal
local changed .hglf/f which remote deleted
use (c)hanged version or (d)elete? c
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local largefile f into a normal file
keep (l)argefile or use (n)ormal file? l
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
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, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large2
$ hg up -Cqr large2
$ echo d | hg merge -r normal --config ui.interactive=Yes
local changed .hglf/f which remote deleted
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
use (c)hanged version or (d)elete? getting changed largefiles
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
0 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
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
normal
swap
$ hg up -Cqr normal
$ hg merge -r large2
remote changed .hglf/f which local deleted
use (c)hanged version or leave (d)eleted? c
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
2013-10-29 01:34:07 +04:00
remote turned local normal file f into a largefile
use (l)argefile or keep (n)ormal file? l
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
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, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
largefiles: systematic testing of merges to/from largefiles bc94b1afd3c9 fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
2013-10-29 01:34:05 +04:00
$ cat f
large2
$ hg up -Cqr normal
$ echo d | hg merge -r large2 --config ui.interactive=Yes
remote changed .hglf/f which local deleted
use (c)hanged version or leave (d)eleted? 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ cat f
normal
$ cd ..
Reference in New Issue Copy Permalink