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

1296 lines
32 KiB
Perl
Raw Normal View History

subrepos: abort commit by default if a subrepo is dirty (BC) This changeset flips the default value of ui.commitsubrepos setting from True to False and adds a --subrepos flag to commit. The commit, status, and diff commands behave like this with regard to recusion and the ui.commitsubrepos setting: | recurses | recurses | by default | with --subrepos --------+---------------+---------------- commit: | commitsubrepo | True status: | False | True diff: | False | True By changing the default from True to False, the table becomes consistent in the two columns: * without --subrepos on the command line, commit will abort if a subrepo is dirty and status/diff wont show changes inside subrepos. * with --subrepos, all three commands will recurse. A --subrepos flag on the command line overrides the config settin.g
2011-10-21 02:33:08 +04:00
Let commit recurse into subrepos by default to match pre-2.0 behavior:
$ echo "[ui]" >> $HGRCPATH
$ echo "commitsubrepos = Yes" >> $HGRCPATH
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg init t
$ cd t
first revision, no sub
$ echo a > a
$ hg ci -Am0
adding a
add first sub
$ echo s = s > .hgsub
$ hg add .hgsub
$ hg init s
$ echo a > s/a
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue2232: committing a subrepo without .hgsub
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg ci -mbad s
abort: can't commit subrepos without .hgsub
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R s ci -Ams0
adding a
$ hg sum
parent: 0:f7b1eb17ad24 tip
0
branch: default
commit: 1 added, 1 subrepos
update: (current)
$ hg ci -m1
tests: add test for fileset 'subrepo' keyword
2012-04-17 09:22:44 +04:00
Revert subrepo and test subrepo fileset keyword:
revert: warn that subrepos cannot be reverted (tests added by mpm)
2011-10-15 03:06:52 +04:00
$ echo b > s/a
tests: add test for fileset 'subrepo' keyword
2012-04-17 09:22:44 +04:00
$ hg revert "set:subrepo('glob:s*')"
revert: add support for reverting subrepos without --no-backup and/or --all When a subrepo is reverted but --no-backup is not set, call revert on the subrepo that is being reverted prior to updating it to the revision specified in the parent repo's .hgsubstate file. The --all flag is passed down to the subrepo when it is being reverted. If the --all flag is not set, all files that are modified on the subrepo will be reverted.
2012-03-28 13:42:17 +04:00
reverting subrepo s
tests: add missing accept of native pathname separator
2012-04-28 03:55:39 +04:00
reverting s/a (glob)
revert: add support for reverting subrepos without --no-backup and/or --all When a subrepo is reverted but --no-backup is not set, call revert on the subrepo that is being reverted prior to updating it to the revision specified in the parent repo's .hgsubstate file. The --all flag is passed down to the subrepo when it is being reverted. If the --all flag is not set, all files that are modified on the subrepo will be reverted.
2012-03-28 13:42:17 +04:00
$ rm s/a.orig
revert: warn that subrepos cannot be reverted (tests added by mpm)
2011-10-15 03:06:52 +04:00
revert: add support for reverting subrepos without --no-backup and/or --all When a subrepo is reverted but --no-backup is not set, call revert on the subrepo that is being reverted prior to updating it to the revision specified in the parent repo's .hgsubstate file. The --all flag is passed down to the subrepo when it is being reverted. If the --all flag is not set, all files that are modified on the subrepo will be reverted.
2012-03-28 13:42:17 +04:00
Revert subrepo with no backup. The "reverting s/a" line is gone since
we're really running 'hg update' in the subrepo:
revert: warn that subrepos cannot be reverted (tests added by mpm)
2011-10-15 03:06:52 +04:00
revert: add support for reverting subrepos without --no-backup and/or --all When a subrepo is reverted but --no-backup is not set, call revert on the subrepo that is being reverted prior to updating it to the revision specified in the parent repo's .hgsubstate file. The --all flag is passed down to the subrepo when it is being reverted. If the --all flag is not set, all files that are modified on the subrepo will be reverted.
2012-03-28 13:42:17 +04:00
$ echo b > s/a
$ hg revert --no-backup s
reverting subrepo s
revert: warn that subrepos cannot be reverted (tests added by mpm)
2011-10-15 03:06:52 +04:00
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue2022: update -C
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ echo b > s/a
$ hg sum
parent: 1:7cf8cfea66e4 tip
1
branch: default
commit: 1 subrepos
update: (current)
$ hg co -C 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg sum
parent: 1:7cf8cfea66e4 tip
1
branch: default
commit: (clean)
update: (current)
cmdutil.bailifchanged: abort for dirty subrepos
2011-10-12 05:18:15 +04:00
commands that require a clean repo should respect subrepos
$ echo b >> s/a
$ hg backout tip
abort: uncommitted changes in subrepo s
[255]
$ hg revert -C -R s s/a
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
add sub sub
$ echo ss = ss > s/.hgsub
$ hg init s/ss
$ echo a > s/ss/a
$ hg -R s add s/.hgsub
$ hg -R s/ss add s/ss/a
$ hg sum
parent: 1:7cf8cfea66e4 tip
1
branch: default
commit: 1 subrepos
update: (current)
$ hg ci -m2
committing subrepository s
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
committing subrepository s/ss (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg sum
parent: 2:df30734270ae tip
2
branch: default
commit: (clean)
update: (current)
commit: abort if a subrepo is modified and ui.commitsubrepos=no The default behaviour is to commit subrepositories with uncommitted changes. In my experience this is usually undesirable: - Changes to dependencies are often debugging leftovers - Real changes should generally be applied on the source project directly, tested then committed. This is not always possible, subversion subrepos may include only a small part of the source project, without the tests. Setting ui.commitsubrepos=no will now abort commits containing such modified subrepositories like: $ hg --config ui.commitsubrepos=no ci -m msg abort: uncommitted changes in subrepo sub I ruled out the hook solution because it does not easily take --include/exclude options in account. Also, my main concern is whether this flag could cause problems with extensions. If there are legitimate reasons for callers to override this behaviour (I could not find any), they might either override at ui level, or we could add an argument to localrepo.commit() later. v2: - Renamed ui.commitsubs to ui.commitsubrepos - Mention the configuration entry in hg help subrepos
2011-02-16 00:25:48 +03:00
bump sub rev (and check it is ignored by ui.commitsubrepos)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ echo b > s/a
$ hg -R s ci -ms1
commit: abort if a subrepo is modified and ui.commitsubrepos=no The default behaviour is to commit subrepositories with uncommitted changes. In my experience this is usually undesirable: - Changes to dependencies are often debugging leftovers - Real changes should generally be applied on the source project directly, tested then committed. This is not always possible, subversion subrepos may include only a small part of the source project, without the tests. Setting ui.commitsubrepos=no will now abort commits containing such modified subrepositories like: $ hg --config ui.commitsubrepos=no ci -m msg abort: uncommitted changes in subrepo sub I ruled out the hook solution because it does not easily take --include/exclude options in account. Also, my main concern is whether this flag could cause problems with extensions. If there are legitimate reasons for callers to override this behaviour (I could not find any), they might either override at ui level, or we could add an argument to localrepo.commit() later. v2: - Renamed ui.commitsubs to ui.commitsubrepos - Mention the configuration entry in hg help subrepos
2011-02-16 00:25:48 +03:00
$ hg --config ui.commitsubrepos=no ci -m3
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
commit: abort if a subrepo is modified and ui.commitsubrepos=no The default behaviour is to commit subrepositories with uncommitted changes. In my experience this is usually undesirable: - Changes to dependencies are often debugging leftovers - Real changes should generally be applied on the source project directly, tested then committed. This is not always possible, subversion subrepos may include only a small part of the source project, without the tests. Setting ui.commitsubrepos=no will now abort commits containing such modified subrepositories like: $ hg --config ui.commitsubrepos=no ci -m msg abort: uncommitted changes in subrepo sub I ruled out the hook solution because it does not easily take --include/exclude options in account. Also, my main concern is whether this flag could cause problems with extensions. If there are legitimate reasons for callers to override this behaviour (I could not find any), they might either override at ui level, or we could add an argument to localrepo.commit() later. v2: - Renamed ui.commitsubs to ui.commitsubrepos - Mention the configuration entry in hg help subrepos
2011-02-16 00:25:48 +03:00
leave sub dirty (and check ui.commitsubrepos=no aborts the commit)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ echo c > s/a
commit: abort if a subrepo is modified and ui.commitsubrepos=no The default behaviour is to commit subrepositories with uncommitted changes. In my experience this is usually undesirable: - Changes to dependencies are often debugging leftovers - Real changes should generally be applied on the source project directly, tested then committed. This is not always possible, subversion subrepos may include only a small part of the source project, without the tests. Setting ui.commitsubrepos=no will now abort commits containing such modified subrepositories like: $ hg --config ui.commitsubrepos=no ci -m msg abort: uncommitted changes in subrepo sub I ruled out the hook solution because it does not easily take --include/exclude options in account. Also, my main concern is whether this flag could cause problems with extensions. If there are legitimate reasons for callers to override this behaviour (I could not find any), they might either override at ui level, or we could add an argument to localrepo.commit() later. v2: - Renamed ui.commitsubs to ui.commitsubrepos - Mention the configuration entry in hg help subrepos
2011-02-16 00:25:48 +03:00
$ hg --config ui.commitsubrepos=no ci -m4
abort: uncommitted changes in subrepo s
subrepos: abort commit by default if a subrepo is dirty (BC) This changeset flips the default value of ui.commitsubrepos setting from True to False and adds a --subrepos flag to commit. The commit, status, and diff commands behave like this with regard to recusion and the ui.commitsubrepos setting: | recurses | recurses | by default | with --subrepos --------+---------------+---------------- commit: | commitsubrepo | True status: | False | True diff: | False | True By changing the default from True to False, the table becomes consistent in the two columns: * without --subrepos on the command line, commit will abort if a subrepo is dirty and status/diff wont show changes inside subrepos. * with --subrepos, all three commands will recurse. A --subrepos flag on the command line overrides the config settin.g
2011-10-21 02:33:08 +04:00
(use --subrepos for recursive commit)
commit: abort if a subrepo is modified and ui.commitsubrepos=no The default behaviour is to commit subrepositories with uncommitted changes. In my experience this is usually undesirable: - Changes to dependencies are often debugging leftovers - Real changes should generally be applied on the source project directly, tested then committed. This is not always possible, subversion subrepos may include only a small part of the source project, without the tests. Setting ui.commitsubrepos=no will now abort commits containing such modified subrepositories like: $ hg --config ui.commitsubrepos=no ci -m msg abort: uncommitted changes in subrepo sub I ruled out the hook solution because it does not easily take --include/exclude options in account. Also, my main concern is whether this flag could cause problems with extensions. If there are legitimate reasons for callers to override this behaviour (I could not find any), they might either override at ui level, or we could add an argument to localrepo.commit() later. v2: - Renamed ui.commitsubs to ui.commitsubrepos - Mention the configuration entry in hg help subrepos
2011-02-16 00:25:48 +03:00
[255]
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
$ hg id
f6affe3fbfaa+ tip
$ hg -R s ci -mc
$ hg id
f6affe3fbfaa+ tip
$ echo d > s/a
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg ci -m4
committing subrepository s
$ hg tip -R s
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
changeset: 4:02dcf1d70411
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: 4
check caching
$ hg co 0
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ hg debugsub
restore
$ hg co
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg debugsub
path s
source s
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
revision 02dcf1d704118aee3ee306ccfa1910850d5b05ef
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
new branch for merge tests
$ hg co 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo t = t >> .hgsub
$ hg init t
$ echo t > t/t
$ hg -R t add t
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
adding t/t (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
5
$ hg ci -m5 # add sub
committing subrepository t
created new head
$ echo t2 > t/t
6
$ hg st -R s
$ hg ci -m6 # change sub
committing subrepository t
$ hg debugsub
path s
source s
revision e4ece1bf43360ddc8f6a96432201a37b7cd27ae4
path t
source t
revision 6747d179aa9a688023c4b0cad32e4c92bb7f34ad
$ echo t3 > t/t
7
$ hg ci -m7 # change sub again for conflict test
committing subrepository t
$ hg rm .hgsub
8
$ hg ci -m8 # remove sub
merge tests
$ hg co -C 3
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge 5 # test adding
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg debugsub
path s
source s
revision fc627a69481fcbe5f1135069e8a3881c023e4cf5
path t
source t
revision 60ca1237c19474e7a3978b0dc1ca4e6f36d51382
$ hg ci -m9
created new head
$ hg merge 6 --debug # test change
searching for copies back to rev 2
resolving manifests
manifestmerge: pass in branchmerge and force separately This will be used in an upcoming patch.
2013-02-08 19:23:23 +04:00
branchmerge: True, force: False, partial: False
merge: make debug output easier to read I always found it hard to figure out what the debug code meant without the separators.
2011-12-09 20:34:53 +04:00
ancestor: 1f14a2e2d3ec, local: f0d2028bf86d+, remote: 1831e14459c4
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
.hgsubstate: versions differ -> m
updating: .hgsubstate 1/1 files (100.00%)
subrepo merge f0d2028bf86d+ 1831e14459c4 1f14a2e2d3ec
subrepo t: other changed, get t:6747d179aa9a688023c4b0cad32e4c92bb7f34ad:hg
getting subrepo t
resolving manifests
manifestmerge: pass in branchmerge and force separately This will be used in an upcoming patch.
2013-02-08 19:23:23 +04:00
branchmerge: False, force: False, partial: False
subrepo: only do clean update when overwrite is set (issue3276) Files in a subrepo were overwritten on update. But this should only happen on a clean update (example: -C is specified). Use the overwrite parameter introduced for svn subrepos in e3640daa4703 to decide whether to merge changes (as update) or remove them (as clean). The new function hg.updaterepo is intruduced to keep all update calls in hg. test-subrepo.t is extended to test if an untracked file is overwritten (issue3276). (Update -C is already tested in many places.) The first two chunks are debugging output which has changed. (Because overwrite is not always true anymore for subrepos) All other tests still pass without any change.
2012-10-24 20:45:22 +04:00
ancestor: 60ca1237c194, local: 60ca1237c194+, remote: 6747d179aa9a
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
t: remote is newer -> g
getting t
tests: update test output (will be folded into parent)
2013-02-10 03:22:04 +04:00
updating: t 1/1 files (100.00%)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg debugsub
path s
source s
revision fc627a69481fcbe5f1135069e8a3881c023e4cf5
path t
source t
revision 6747d179aa9a688023c4b0cad32e4c92bb7f34ad
$ echo conflict > t/t
$ hg ci -m10
committing subrepository t
$ HGMERGE=internal:merge hg merge --debug 7 # test conflict
searching for copies back to rev 2
resolving manifests
manifestmerge: pass in branchmerge and force separately This will be used in an upcoming patch.
2013-02-08 19:23:23 +04:00
branchmerge: True, force: False, partial: False
merge: make debug output easier to read I always found it hard to figure out what the debug code meant without the separators.
2011-12-09 20:34:53 +04:00
ancestor: 1831e14459c4, local: e45c8b14af55+, remote: f94576341bcf
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
.hgsubstate: versions differ -> m
updating: .hgsubstate 1/1 files (100.00%)
subrepo merge e45c8b14af55+ f94576341bcf 1831e14459c4
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepo t: both sides changed
subrepository t diverged (local revision: 20a0db6fbf6c, remote revision: 7af322bc1198)
(M)erge, keep (l)ocal or keep (r)emote? m
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
merging subrepo t
searching for copies back to rev 2
resolving manifests
manifestmerge: pass in branchmerge and force separately This will be used in an upcoming patch.
2013-02-08 19:23:23 +04:00
branchmerge: True, force: False, partial: False
merge: make debug output easier to read I always found it hard to figure out what the debug code meant without the separators.
2011-12-09 20:34:53 +04:00
ancestor: 6747d179aa9a, local: 20a0db6fbf6c+, remote: 7af322bc1198
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
t: versions differ -> m
merge: delay debug messages for merge actions Show messages at a point where the actions have been sorted, thus preparing for backout of 14f4258e3526. This makes manifestmerge more of a silent operation, just like 'copies' is. Indent 'preserving' messages to make them subordinate to the action logging so they fit in the new context. (The 'preserving' messages are quite redundant and could also be removed completely.)
2013-01-25 02:57:44 +04:00
preserving t for resolve of t
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
updating: t 1/1 files (100.00%)
picked tool 'internal:merge' for t (binary False symlink False)
merging t
my t@20a0db6fbf6c+ other t@7af322bc1198 ancestor t@6747d179aa9a
warning: conflicts during merge.
merge: give a special message for internal:merge failure (issue3105)
2011-11-17 04:04:19 +04:00
merging t incomplete! (edit conflicts, then use 'hg resolve --mark')
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
merge: suggest 'hg up -C .' for discarding changes, not 'hg up -C' Without specifying the parent revision of the working copy, users will update to tip, which is most likely the other head they were trying to merge, not the revision they were at before the merge.
2010-09-13 03:05:53 +04:00
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepo t: merge with t:7af322bc1198a32402fe903e0b7ebcfc5c9bf8f4:hg
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
should conflict
$ cat t/t
<<<<<<< local
conflict
=======
t3
>>>>>>> other
clone
$ cd ..
$ hg clone t tc
updating to branch default
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
cloning subrepo s from $TESTTMP/t/s
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
cloning subrepo s/ss from $TESTTMP/t/s/ss (glob)
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
cloning subrepo t from $TESTTMP/t/t
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd tc
$ hg debugsub
path s
source s
revision fc627a69481fcbe5f1135069e8a3881c023e4cf5
path t
source t
revision 20a0db6fbf6c3d2836e6519a642ae929bfc67c0e
push
$ echo bah > t/t
$ hg ci -m11
committing subrepository t
$ hg push
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
pushing to $TESTTMP/t (glob)
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
no changes made to subrepo s/ss since last push to $TESTTMP/t/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
no changes made to subrepo s since last push to $TESTTMP/t/s
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
pushing subrepo t to $TESTTMP/t/t
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
push -f
$ echo bah > s/a
$ hg ci -m12
committing subrepository s
$ hg push
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
pushing to $TESTTMP/t (glob)
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
no changes made to subrepo s/ss since last push to $TESTTMP/t/s/ss (glob)
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
pushing subrepo s to $TESTTMP/t/s
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
searching for changes
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
2012-12-14 02:37:53 +04:00
abort: push creates new remote head 12a213df6fa9! (in subrepo s)
push: hide description about "-f" in the hint to prevent from using it easily "use push -f to force" in the hint at abortion of "hg push" may cause novice users to execute "push -f" easily without understanding about problems of multiple branch heads in the repository. This patch hides description about "-f" in the hint, and leads into seeing "hg help push" for details about pushing new heads.
2013-10-03 18:16:06 +04:00
(merge or see "hg help push" for details about pushing new heads)
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg push -f
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
pushing to $TESTTMP/t (glob)
pushing subrepo s/ss to $TESTTMP/t/s/ss (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
searching for changes
no changes found
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
pushing subrepo s to $TESTTMP/t/s
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
pushing subrepo t to $TESTTMP/t/t
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
searching for changes
no changes found
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
check that unmodified subrepos are not pushed
$ hg clone . ../tcc
updating to branch default
cloning subrepo s from $TESTTMP/tc/s
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
cloning subrepo s/ss from $TESTTMP/tc/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
cloning subrepo t from $TESTTMP/tc/t
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
the subrepos on the new clone have nothing to push to its source
$ hg push -R ../tcc .
pushing to .
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
no changes made to subrepo s/ss since last push to s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
no changes made to subrepo s since last push to s
no changes made to subrepo t since last push to t
searching for changes
no changes found
[1]
the subrepos on the source do not have a clean store versus the clone target
because they were never explicitly pushed to the source
$ hg push ../tcc
pushing to ../tcc
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
pushing subrepo s/ss to ../tcc/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
searching for changes
no changes found
pushing subrepo s to ../tcc/s
searching for changes
no changes found
pushing subrepo t to ../tcc/t
searching for changes
no changes found
searching for changes
no changes found
[1]
after push their stores become clean
$ hg push ../tcc
pushing to ../tcc
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
no changes made to subrepo s/ss since last push to ../tcc/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
no changes made to subrepo s since last push to ../tcc/s
no changes made to subrepo t since last push to ../tcc/t
searching for changes
no changes found
[1]
updating a subrepo to a different revision or changing
its working directory does not make its store dirty
$ hg -R s update '.^'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg push
check-code: add more path sep glob checks
2013-05-03 00:21:47 +04:00
pushing to $TESTTMP/t (glob)
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
no changes made to subrepo s/ss since last push to $TESTTMP/t/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
no changes made to subrepo s since last push to $TESTTMP/t/s
no changes made to subrepo t since last push to $TESTTMP/t/t
searching for changes
no changes found
[1]
$ echo foo >> s/a
$ hg push
check-code: add more path sep glob checks
2013-05-03 00:21:47 +04:00
pushing to $TESTTMP/t (glob)
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
no changes made to subrepo s/ss since last push to $TESTTMP/t/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
no changes made to subrepo s since last push to $TESTTMP/t/s
no changes made to subrepo t since last push to $TESTTMP/t/t
searching for changes
no changes found
[1]
$ hg -R s update -C tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
committing into a subrepo makes its store (but not its parent's store) dirty
$ echo foo >> s/ss/a
$ hg -R s/ss commit -m 'test dirty store detection'
$ hg push
check-code: add more path sep glob checks
2013-05-03 00:21:47 +04:00
pushing to $TESTTMP/t (glob)
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
pushing subrepo s/ss to $TESTTMP/t/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
no changes made to subrepo s since last push to $TESTTMP/t/s
no changes made to subrepo t since last push to $TESTTMP/t/t
searching for changes
no changes found
[1]
a subrepo store may be clean versus one repo but not versus another
$ hg push
check-code: add more path sep glob checks
2013-05-03 00:21:47 +04:00
pushing to $TESTTMP/t (glob)
tests: sprinkle globs over largefiles/subrepo tests for Windows
2013-05-02 22:26:43 +04:00
no changes made to subrepo s/ss since last push to $TESTTMP/t/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
no changes made to subrepo s since last push to $TESTTMP/t/s
no changes made to subrepo t since last push to $TESTTMP/t/t
searching for changes
no changes found
[1]
$ hg push ../tcc
pushing to ../tcc
tests: fix another Windows path issue
2013-05-10 00:09:36 +04:00
pushing subrepo s/ss to ../tcc/s/ss (glob)
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
no changes made to subrepo s since last push to ../tcc/s
no changes made to subrepo t since last push to ../tcc/t
searching for changes
no changes found
[1]
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
update
$ cd ../t
$ hg up -C # discard our earlier merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo blah > t/t
$ hg ci -m13
committing subrepository t
subrepo: fix exception on revert when "all" option is omitted Since 0f22f83473ea, backout does not set opts['all'], which causes KeyError at hgsubrepo.revert.
2013-04-15 18:52:57 +04:00
backout calls revert internally with minimal opts, which should not raise
KeyError
$ hg backout ".^"
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg up -C # discard changes
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
pull
$ cd ../tc
$ hg pull
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
pulling from $TESTTMP/t (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
should pull t
$ hg up
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
pulling subrepo t from $TESTTMP/t/t
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.
2013-03-09 00:50:27 +04:00
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ cat t/t
blah
bogus subrepo path aborts
$ echo 'bogus=[boguspath' >> .hgsub
$ hg ci -m 'bogus subrepo path'
abort: missing ] in subrepo source
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue1986: merge aborts when trying to merge a subrepo that
shouldn't need merging
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
# subrepo layout
#
# o 5 br
# /|
# o | 4 default
# | |
# | o 3 br
# |/|
# o | 2 default
# | |
# | o 1 br
# |/
# o 0 default
$ cd ..
$ rm -rf sub
$ hg init main
$ cd main
$ hg init s
$ cd s
$ echo a > a
$ hg ci -Am1
adding a
$ hg branch br
marked working directory as branch br
branch: warn on branching
2011-12-09 00:32:44 +04:00
(branches are permanent and global, did you want a bookmark?)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ echo a >> a
$ hg ci -m1
$ hg up default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo b > b
$ hg ci -Am1
adding b
$ hg up br
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m1
$ hg up 2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo c > c
$ hg ci -Am1
adding c
$ hg up 3
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge 4
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m1
# main repo layout:
#
# * <-- try to merge default into br again
# .`|
# . o 5 br --> substate = 5
# . |
# o | 4 default --> substate = 4
# | |
# | o 3 br --> substate = 2
# |/|
# o | 2 default --> substate = 2
# | |
# | o 1 br --> substate = 3
# |/
# o 0 default --> substate = 2
$ cd ..
$ echo 's = s' > .hgsub
$ hg -R s up 2
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg ci -Am1
adding .hgsub
$ hg branch br
marked working directory as branch br
branch: warn on branching
2011-12-09 00:32:44 +04:00
(branches are permanent and global, did you want a bookmark?)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ echo b > b
$ hg -R s up 3
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg ci -Am1
adding b
$ hg up default
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo c > c
$ hg ci -Am1
adding c
$ hg up 1
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge 2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m1
$ hg up 2
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg -R s up 4
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo d > d
$ hg ci -Am1
adding d
$ hg up 3
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg -R s up 5
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo e > e
$ hg ci -Am1
adding e
$ hg up 5
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge 4 # try to merge default into br again
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: f8f13b33206e, remote revision: a3f9062a4f88)
(M)erge, keep (l)ocal or keep (r)emote? m
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ cd ..
test subrepo delete from .hgsubstate
$ hg init testdelete
$ mkdir testdelete/nested testdelete/nested2
$ hg init testdelete/nested
$ hg init testdelete/nested2
$ echo test > testdelete/nested/foo
$ echo test > testdelete/nested2/foo
$ hg -R testdelete/nested add
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
adding testdelete/nested/foo (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R testdelete/nested2 add
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
adding testdelete/nested2/foo (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R testdelete/nested ci -m test
$ hg -R testdelete/nested2 ci -m test
$ echo nested = nested > testdelete/.hgsub
$ echo nested2 = nested2 >> testdelete/.hgsub
$ hg -R testdelete add
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
adding testdelete/.hgsub (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R testdelete ci -m "nested 1 & 2 added"
$ echo nested = nested > testdelete/.hgsub
$ hg -R testdelete ci -m "nested 2 deleted"
$ cat testdelete/.hgsubstate
bdf5c9a3103743d900b12ae0db3ffdcfd7b0d878 nested
$ hg -R testdelete remove testdelete/.hgsub
$ hg -R testdelete ci -m ".hgsub deleted"
$ cat testdelete/.hgsubstate
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
bdf5c9a3103743d900b12ae0db3ffdcfd7b0d878 nested
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
test repository cloning
$ mkdir mercurial mercurial2
$ hg init nested_absolute
$ echo test > nested_absolute/foo
$ hg -R nested_absolute add
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
adding nested_absolute/foo (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R nested_absolute ci -mtest
$ cd mercurial
$ hg init nested_relative
$ echo test2 > nested_relative/foo2
$ hg -R nested_relative add
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
adding nested_relative/foo2 (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R nested_relative ci -mtest2
$ hg init main
$ echo "nested_relative = ../nested_relative" > main/.hgsub
$ echo "nested_absolute = `pwd`/nested_absolute" >> main/.hgsub
$ hg -R main add
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
adding main/.hgsub (glob)
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R main ci -m "add subrepos"
$ cd ..
$ hg clone mercurial/main mercurial2/main
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat mercurial2/main/nested_absolute/.hg/hgrc \
> mercurial2/main/nested_relative/.hg/hgrc
[paths]
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
default = $TESTTMP/mercurial/nested_absolute
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
[paths]
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
default = $TESTTMP/mercurial/nested_relative
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ rm -rf mercurial mercurial2
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue1977: multirepo push should fail if subrepo push fails
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg init repo
$ hg init repo/s
$ echo a > repo/s/a
$ hg -R repo/s ci -Am0
adding a
$ echo s = s > repo/.hgsub
$ hg -R repo ci -Am1
adding .hgsub
$ hg clone repo repo2
updating to branch default
tests: remove glob lines which unnecessary match / for \ on windows This lines were reported as unnecessary when running the tests on windows because the path was already printed with a slash and not a backslash.
2013-02-24 01:54:57 +04:00
cloning subrepo s from $TESTTMP/repo/s
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg -q -R repo2 pull -u
$ echo 1 > repo2/s/a
$ hg -R repo2/s ci -m2
$ hg -q -R repo2/s push
$ hg -R repo2/s up -C 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
subrepo: only do clean update when overwrite is set (issue3276) Files in a subrepo were overwritten on update. But this should only happen on a clean update (example: -C is specified). Use the overwrite parameter introduced for svn subrepos in e3640daa4703 to decide whether to merge changes (as update) or remove them (as clean). The new function hg.updaterepo is intruduced to keep all update calls in hg. test-subrepo.t is extended to test if an untracked file is overwritten (issue3276). (Update -C is already tested in many places.) The first two chunks are debugging output which has changed. (Because overwrite is not always true anymore for subrepos) All other tests still pass without any change.
2012-10-24 20:45:22 +04:00
$ echo 2 > repo2/s/b
$ hg -R repo2/s ci -m3 -A
adding b
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
created new head
$ hg -R repo2 ci -m3
$ hg -q -R repo2 push
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
2012-12-14 02:37:53 +04:00
abort: push creates new remote head cc505f09a8b2! (in subrepo s)
push: hide description about "-f" in the hint to prevent from using it easily "use push -f to force" in the hint at abortion of "hg push" may cause novice users to execute "push -f" easily without understanding about problems of multiple branch heads in the repository. This patch hides description about "-f" in the hint, and leads into seeing "hg help push" for details about pushing new heads.
2013-10-03 18:16:06 +04:00
(merge or see "hg help push" for details about pushing new heads)
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ hg -R repo update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
subrepo: only do clean update when overwrite is set (issue3276) Files in a subrepo were overwritten on update. But this should only happen on a clean update (example: -C is specified). Use the overwrite parameter introduced for svn subrepos in e3640daa4703 to decide whether to merge changes (as update) or remove them (as clean). The new function hg.updaterepo is intruduced to keep all update calls in hg. test-subrepo.t is extended to test if an untracked file is overwritten (issue3276). (Update -C is already tested in many places.) The first two chunks are debugging output which has changed. (Because overwrite is not always true anymore for subrepos) All other tests still pass without any change.
2012-10-24 20:45:22 +04:00
test if untracked file is not overwritten
$ echo issue3276_ok > repo/s/b
$ hg -R repo2 push -f -q
$ hg -R repo update
b: untracked file differs
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
2012-12-14 02:37:53 +04:00
abort: untracked files in working directory differ from files in requested revision (in subrepo s)
subrepo: only do clean update when overwrite is set (issue3276) Files in a subrepo were overwritten on update. But this should only happen on a clean update (example: -C is specified). Use the overwrite parameter introduced for svn subrepos in e3640daa4703 to decide whether to merge changes (as update) or remove them (as clean). The new function hg.updaterepo is intruduced to keep all update calls in hg. test-subrepo.t is extended to test if an untracked file is overwritten (issue3276). (Update -C is already tested in many places.) The first two chunks are debugging output which has changed. (Because overwrite is not always true anymore for subrepos) All other tests still pass without any change.
2012-10-24 20:45:22 +04:00
[255]
$ cat repo/s/b
issue3276_ok
$ rm repo/s/b
$ hg -R repo revert --all
test-subrepo: adapt for Windows after 6e587aaeb4ef Fixes @@ -606,7 +606,7 @@ issue3276_ok $ rm repo/s/b $ hg -R repo revert --all - reverting repo/.hgsubstate + reverting repo\.hgsubstate reverting subrepo s $ hg -R repo update 1 files updated, 0 files merged, 0 files removed, 0 files unresolved on Windows
2012-11-02 23:47:03 +04:00
reverting repo/.hgsubstate (glob)
subrepo: only do clean update when overwrite is set (issue3276) Files in a subrepo were overwritten on update. But this should only happen on a clean update (example: -C is specified). Use the overwrite parameter introduced for svn subrepos in e3640daa4703 to decide whether to merge changes (as update) or remove them (as clean). The new function hg.updaterepo is intruduced to keep all update calls in hg. test-subrepo.t is extended to test if an untracked file is overwritten (issue3276). (Update -C is already tested in many places.) The first two chunks are debugging output which has changed. (Because overwrite is not always true anymore for subrepos) All other tests still pass without any change.
2012-10-24 20:45:22 +04:00
reverting subrepo s
$ hg -R repo update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat repo/s/b
2
tests: unify test-subrepo
2010-08-17 18:52:05 +04:00
$ rm -rf repo2 repo
subrepo: abort instead of pushing/pulling to the repo itself _abssource will now abort (or return None) in the rare cases where no push/pull path can be found.
2010-10-19 05:56:20 +04:00
Issue1852 subrepos with relative paths always push/pull relative to default
Prepare a repo with subrepo
$ hg init issue1852a
$ cd issue1852a
$ hg init sub/repo
$ echo test > sub/repo/foo
$ hg -R sub/repo add sub/repo/foo
$ echo sub/repo = sub/repo > .hgsub
$ hg add .hgsub
$ hg ci -mtest
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
committing subrepository sub/repo (glob)
subrepo: abort instead of pushing/pulling to the repo itself _abssource will now abort (or return None) in the rare cases where no push/pull path can be found.
2010-10-19 05:56:20 +04:00
$ echo test >> sub/repo/foo
$ hg ci -mtest
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
committing subrepository sub/repo (glob)
subrepo: abort instead of pushing/pulling to the repo itself _abssource will now abort (or return None) in the rare cases where no push/pull path can be found.
2010-10-19 05:56:20 +04:00
$ cd ..
Create repo without default path, pull top repo, and see what happens on update
$ hg init issue1852b
$ hg -R issue1852b pull issue1852a
pulling from issue1852a
requesting all changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 3 changes to 2 files
(run 'hg update' to get a working copy)
$ hg -R issue1852b update
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
2012-12-14 02:37:53 +04:00
abort: default path for subrepository not found (in subrepo sub/repo) (glob)
subrepo: abort instead of pushing/pulling to the repo itself _abssource will now abort (or return None) in the rare cases where no push/pull path can be found.
2010-10-19 05:56:20 +04:00
[255]
ui: add support for fully printing chained exception stacks in ui.traceback() Currently, only SubrepoAbort has a cause chained to it.
2013-02-09 23:15:34 +04:00
Ensure a full traceback, not just the SubrepoAbort part
$ hg -R issue1852b update --traceback 2>&1 | grep 'raise util\.Abort'
raise util.Abort(_("default path for subrepository not found"))
subrepo: abort instead of pushing/pulling to the repo itself _abssource will now abort (or return None) in the rare cases where no push/pull path can be found.
2010-10-19 05:56:20 +04:00
Pull -u now doesn't help
$ hg -R issue1852b pull -u issue1852a
pulling from issue1852a
searching for changes
no changes found
Try the same, but with pull -u
$ hg init issue1852c
$ hg -R issue1852c pull -r0 -u issue1852a
pulling from issue1852a
adding changesets
adding manifests
adding file changes
added 1 changesets with 2 changes to 2 files
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
cloning subrepo sub/repo from issue1852a/sub/repo (glob)
subrepo: propagate non-default pull/push path to relative subrepos (issue1852)
2010-10-27 02:28:40 +04:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
subrepo: abort instead of pushing/pulling to the repo itself _abssource will now abort (or return None) in the rare cases where no push/pull path can be found.
2010-10-19 05:56:20 +04:00
Try to push from the other side
subrepo: propagate non-default pull/push path to relative subrepos (issue1852)
2010-10-27 02:28:40 +04:00
$ hg -R issue1852a push `pwd`/issue1852c
check-code: add more path sep glob checks
2013-05-03 00:21:47 +04:00
pushing to $TESTTMP/issue1852c (glob)
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
pushing subrepo sub/repo to $TESTTMP/issue1852c/sub/repo (glob)
subrepo: propagate non-default pull/push path to relative subrepos (issue1852)
2010-10-27 02:28:40 +04:00
searching for changes
no changes found
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
subrepo: do not report known files inside repositories as unknown
2011-01-04 14:53:11 +03:00
subrepo: respect non-default path for incoming/outgoing Push and pull set repo._subtoppath before pushing or pulling subrepos. The incoming and outgoing commands needed to do the same.
2011-05-18 17:13:26 +04:00
Incoming and outgoing should not use the default path:
$ hg clone -q issue1852a issue1852d
$ hg -R issue1852d outgoing --subrepos issue1852c
comparing with issue1852c
searching for changes
no changes found
comparing with issue1852c/sub/repo
searching for changes
no changes found
[1]
$ hg -R issue1852d incoming --subrepos issue1852c
comparing with issue1852c
searching for changes
no changes found
comparing with issue1852c/sub/repo
searching for changes
no changes found
[1]
subrepo: do not report known files inside repositories as unknown
2011-01-04 14:53:11 +03:00
Check status of files when none of them belong to the first
subrepository:
$ hg init subrepo-status
$ cd subrepo-status
$ hg init subrepo-1
$ hg init subrepo-2
$ cd subrepo-2
$ touch file
$ hg add file
$ cd ..
$ echo subrepo-1 = subrepo-1 > .hgsub
$ echo subrepo-2 = subrepo-2 >> .hgsub
$ hg add .hgsub
$ hg ci -m 'Added subrepos'
committing subrepository subrepo-2
$ hg st subrepo-2/file
subrepo: make update -C clean the working directory for svn subrepos This makes 'hg update --clean' behave the same way for both kinds of subrepositories. Before Subversion subrepos did not take the clean parameter into account, but just updated to the given revision and merged uncommitted changes into that.
2011-01-31 15:33:41 +03:00
share: always set default path to work with subrepos (issue3518) set the default path in any case because creating subrepo looks this up. Subrepos are cloned, not shared.
2012-10-27 14:38:59 +04:00
Check that share works with subrepo
$ hg --config extensions.share= share . ../shared
updating working directory
cloning subrepo subrepo-2 from $TESTTMP/subrepo-status/subrepo-2
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ test -f ../shared/subrepo-1/.hg/sharedpath
[1]
subrepo: use sharepath if available when locating the source repo This is an alternative fix for issue3518, enabling sharing of repositories with subrepos, without unconditionally setting the default path in the resulting repo's hgrc file. Better test coverage is added here, but won't prove this code is working until f48752441ca0 is backed out. The problem with the original fix is, if a default path is not available to be copied over from the share source, the default path on the resulting repo is set to the source location. Since that's where the actual repository is stored, the path is essentially self-referential, so push, pull, incoming and outgoing effectively operate on itself. While incoming and outgoing make it look like nothing was changed, push currently hangs (see issue3657). In this case where there is not a real default path, these operations should abort with "default(-push) not found", like the source repo would. Note this problem with the original fix affected repos without subrepos too.
2012-11-28 05:56:27 +04:00
$ hg -R ../shared in
share: backout f48752441ca0, except the test Locating the share source when no default path is available is now handled in subrepo._abssource(), so unconditionally setting a default path (and the associated problems) can be avoided. The test change reflects the fact that a default path is no longer set on the resulting share.
2012-11-28 06:31:59 +04:00
abort: repository default not found!
[255]
subrepo: use sharepath if available when locating the source repo This is an alternative fix for issue3518, enabling sharing of repositories with subrepos, without unconditionally setting the default path in the resulting repo's hgrc file. Better test coverage is added here, but won't prove this code is working until f48752441ca0 is backed out. The problem with the original fix is, if a default path is not available to be copied over from the share source, the default path on the resulting repo is set to the source location. Since that's where the actual repository is stored, the path is essentially self-referential, so push, pull, incoming and outgoing effectively operate on itself. While incoming and outgoing make it look like nothing was changed, push currently hangs (see issue3657). In this case where there is not a real default path, these operations should abort with "default(-push) not found", like the source repo would. Note this problem with the original fix affected repos without subrepos too.
2012-11-28 05:56:27 +04:00
$ hg -R ../shared/subrepo-2 showconfig paths
paths.default=$TESTTMP/subrepo-status/subrepo-2
$ hg -R ../shared/subrepo-1 sum --remote
parent: -1:000000000000 tip (empty repository)
branch: default
commit: (clean)
update: (current)
remote: (synced)
share: always set default path to work with subrepos (issue3518) set the default path in any case because creating subrepo looks this up. Subrepos are cloned, not shared.
2012-10-27 14:38:59 +04:00
subrepo: make update -C clean the working directory for svn subrepos This makes 'hg update --clean' behave the same way for both kinds of subrepositories. Before Subversion subrepos did not take the clean parameter into account, but just updated to the given revision and merged uncommitted changes into that.
2011-01-31 15:33:41 +03:00
Check hg update --clean
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ cd $TESTTMP/t
subrepo: make update -C clean the working directory for svn subrepos This makes 'hg update --clean' behave the same way for both kinds of subrepositories. Before Subversion subrepos did not take the clean parameter into account, but just updated to the given revision and merged uncommitted changes into that.
2011-01-31 15:33:41 +03:00
$ rm -r t/t.orig
$ hg status -S --all
C .hgsub
C .hgsubstate
C a
C s/.hgsub
C s/.hgsubstate
C s/a
C s/ss/a
C t/t
$ echo c1 > s/a
$ cd s
$ echo c1 > b
$ echo c1 > c
$ hg add b
$ cd ..
$ hg status -S
M s/a
A s/b
? s/c
$ hg update -C
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg status -S
? s/b
? s/c
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
Sticky subrepositories, no changes
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ cd $TESTTMP/t
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ hg id
925c17564ef8 tip
$ hg -R s id
12a213df6fa9 tip
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
52c0adc0515a tip
$ hg update 11
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
365661e5936a
$ hg -R s id
fc627a69481f
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
e95bcfa18a35
Sticky subrepositorys, file changes
$ touch s/f1
$ touch t/f1
$ hg add -S s/f1
$ hg add -S t/f1
$ hg id
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
365661e5936a+
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ hg -R s id
fc627a69481f+
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
e95bcfa18a35+
$ hg update tip
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: fc627a69481f, remote revision: 12a213df6fa9)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for s differ
use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
l
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository t diverged (local revision: e95bcfa18a35, remote revision: 52c0adc0515a)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for t differ
use (l)ocal source (e95bcfa18a35) or (r)emote source (52c0adc0515a)?
l
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
925c17564ef8+ tip
$ hg -R s id
fc627a69481f+
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
e95bcfa18a35+
$ hg update --clean tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Sticky subrepository, revision updates
$ hg id
925c17564ef8 tip
$ hg -R s id
12a213df6fa9 tip
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
52c0adc0515a tip
$ cd s
$ hg update -r -2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ../t
$ hg update -r 2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ..
$ hg update 10
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: 12a213df6fa9, remote revision: fc627a69481f)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepository t diverged (local revision: 52c0adc0515a, remote revision: 20a0db6fbf6c)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for t differ (in checked out version)
use (l)ocal source (7af322bc1198) or (r)emote source (20a0db6fbf6c)?
l
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
e45c8b14af55+
$ hg -R s id
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
02dcf1d70411
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
7af322bc1198
Sticky subrepository, file changes and revision updates
$ touch s/f1
$ touch t/f1
$ hg add -S s/f1
$ hg add -S t/f1
$ hg id
e45c8b14af55+
$ hg -R s id
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
02dcf1d70411+
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
7af322bc1198+
$ hg update tip
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: 12a213df6fa9, remote revision: 12a213df6fa9)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for s differ
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
use (l)ocal source (02dcf1d70411) or (r)emote source (12a213df6fa9)?
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
l
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository t diverged (local revision: 52c0adc0515a, remote revision: 52c0adc0515a)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for t differ
use (l)ocal source (7af322bc1198) or (r)emote source (52c0adc0515a)?
l
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
925c17564ef8+ tip
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ hg -R s id
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
02dcf1d70411+
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
7af322bc1198+
Sticky repository, update --clean
$ hg update --clean tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
925c17564ef8 tip
$ hg -R s id
12a213df6fa9 tip
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
52c0adc0515a tip
Test subrepo already at intended revision:
$ cd s
$ hg update fc627a69481f
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ..
$ hg update 11
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: 12a213df6fa9, remote revision: fc627a69481f)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -n
11+
$ hg -R s id
fc627a69481f
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg -R t id
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
e95bcfa18a35
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
Test that removing .hgsubstate doesn't break anything:
$ hg rm -f .hgsubstate
$ hg ci -mrm
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
nothing changed
[1]
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
$ hg log -vr tip
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
changeset: 13:925c17564ef8
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
files: .hgsubstate
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
description:
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
13
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
Test that removing .hgsub removes .hgsubstate:
$ hg rm .hgsub
$ hg ci -mrm2
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
created new head
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
$ hg log -vr tip
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
changeset: 14:2400bccd50af
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
tag: tip
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
parent: 11:365661e5936a
subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844) We shouldn't try to process subrepos if .hgsub isn't present and we should remove .hgsubstate if .hgsub is marked for removal.
2011-06-07 00:17:40 +04:00
user: test
date: Thu Jan 01 00:00:00 1970 +0000
files: .hgsub .hgsubstate
description:
rm2
test-subrepo: test for Issue3153
2011-12-15 19:18:10 +04:00
Test issue3153: diff -S with deleted subrepos
$ hg diff --nodates -S -c .
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
diff -r 365661e5936a -r 2400bccd50af .hgsub
test-subrepo: test for Issue3153
2011-12-15 19:18:10 +04:00
--- a/.hgsub
+++ /dev/null
@@ -1,2 +0,0 @@
-s = s
-t = t
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
2012-02-07 01:10:01 +04:00
diff -r 365661e5936a -r 2400bccd50af .hgsubstate
test-subrepo: test for Issue3153
2011-12-15 19:18:10 +04:00
--- a/.hgsubstate
+++ /dev/null
@@ -1,2 +0,0 @@
-fc627a69481fcbe5f1135069e8a3881c023e4cf5 s
-e95bcfa18a358dc4936da981ebf4147b4cad1362 t
merge with stable
2011-12-15 19:26:33 +04:00
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
Test behavior of add for explicit path in subrepo:
$ cd ..
tests: add test for behavior of forget for explicit path in subrepo Adds a section to test-subrepo.t that demonstrates the current behavior when you pass the full path to a file in a subrepo to hg forget.
2011-11-10 04:46:49 +04:00
$ hg init explicit
$ cd explicit
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
$ echo s = s > .hgsub
$ hg add .hgsub
$ hg init s
$ hg ci -m0
add: support adding explicit files in subrepos Change the behavior of the add command such that explicit paths in subrepos are always added. This eliminates the previous behavior where if you called "hg add" for an explicit path in a subrepo without specifying the -S option, it would be silently ignored. If you specify patterns, or no arguments at all, the -S option will still be needed to activate recursion into subrepos.
2011-11-02 09:17:11 +04:00
Adding with an explicit path in a subrepo adds the file
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
$ echo c1 > f1
$ echo c2 > s/f2
$ hg st -S
? f1
? s/f2
$ hg add s/f2
$ hg st -S
add: support adding explicit files in subrepos Change the behavior of the add command such that explicit paths in subrepos are always added. This eliminates the previous behavior where if you called "hg add" for an explicit path in a subrepo without specifying the -S option, it would be silently ignored. If you specify patterns, or no arguments at all, the -S option will still be needed to activate recursion into subrepos.
2011-11-02 09:17:11 +04:00
A s/f2
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
? f1
add: support adding explicit files in subrepos Change the behavior of the add command such that explicit paths in subrepos are always added. This eliminates the previous behavior where if you called "hg add" for an explicit path in a subrepo without specifying the -S option, it would be silently ignored. If you specify patterns, or no arguments at all, the -S option will still be needed to activate recursion into subrepos.
2011-11-02 09:17:11 +04:00
$ hg ci -R s -m0
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
$ hg ci -Am1
adding f1
add: support adding explicit files in subrepos Change the behavior of the add command such that explicit paths in subrepos are always added. This eliminates the previous behavior where if you called "hg add" for an explicit path in a subrepo without specifying the -S option, it would be silently ignored. If you specify patterns, or no arguments at all, the -S option will still be needed to activate recursion into subrepos.
2011-11-02 09:17:11 +04:00
Adding with an explicit path in a subrepo with -S has the same behavior
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
$ echo c3 > f3
$ echo c4 > s/f4
$ hg st -S
? f3
? s/f4
$ hg add -S s/f4
$ hg st -S
A s/f4
? f3
$ hg ci -R s -m1
$ hg ci -Ama2
adding f3
Adding without a path or pattern silently ignores subrepos
$ echo c5 > f5
$ echo c6 > s/f6
$ echo c7 > s/f7
$ hg st -S
? f5
? s/f6
? s/f7
$ hg add
adding f5
$ hg st -S
A f5
? s/f6
? s/f7
$ hg ci -R s -Am2
adding f6
adding f7
$ hg ci -m3
Adding without a path or pattern with -S also adds files in subrepos
$ echo c8 > f8
$ echo c9 > s/f9
$ echo c10 > s/f10
$ hg st -S
? f8
? s/f10
? s/f9
$ hg add -S
adding f8
tests: add missing '(glob)'s to match '\' in paths in test output on windows
2011-11-16 06:45:14 +04:00
adding s/f10 (glob)
adding s/f9 (glob)
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
$ hg st -S
A f8
A s/f10
A s/f9
$ hg ci -R s -m3
$ hg ci -m4
Adding with a pattern silently ignores subrepos
$ echo c11 > fm11
$ echo c12 > fn12
$ echo c13 > s/fm13
$ echo c14 > s/fn14
$ hg st -S
? fm11
? fn12
? s/fm13
? s/fn14
$ hg add 'glob:**fm*'
adding fm11
$ hg st -S
A fm11
? fn12
? s/fm13
? s/fn14
$ hg ci -R s -Am4
adding fm13
adding fn14
$ hg ci -Am5
adding fn12
Adding with a pattern with -S also adds matches in subrepos
$ echo c15 > fm15
$ echo c16 > fn16
$ echo c17 > s/fm17
$ echo c18 > s/fn18
$ hg st -S
? fm15
? fn16
? s/fm17
? s/fn18
$ hg add -S 'glob:**fm*'
adding fm15
tests: add missing '(glob)'s to match '\' in paths in test output on windows
2011-11-16 06:45:14 +04:00
adding s/fm17 (glob)
tests: add test for add of explicit path in subrepo Add test coverage for the existing behavior where adds of explicit paths in subrepos are silently ignored. This is in preparation for changing the behavior of the add command to have better support for subrepos.
2011-11-02 07:53:29 +04:00
$ hg st -S
A fm15
A s/fm17
? fn16
? s/fn18
$ hg ci -R s -Am5
adding fn18
$ hg ci -Am6
adding fn16
tests: add test for behavior of forget for explicit path in subrepo Adds a section to test-subrepo.t that demonstrates the current behavior when you pass the full path to a file in a subrepo to hg forget.
2011-11-10 04:46:49 +04:00
Test behavior of forget for explicit path in subrepo:
forget: support forgetting explicit paths in subrepos Change the behavior of the forget command such that explicit paths in subrepos are handled by forgetting the file in the subrepo. This eliminates the previous behavior where if you called "hg forget" for an explicit path in a subrepo, it would state that the file is already untracked.
2011-11-10 04:46:51 +04:00
Forgetting an explicit path in a subrepo untracks the file
tests: add test for behavior of forget for explicit path in subrepo Adds a section to test-subrepo.t that demonstrates the current behavior when you pass the full path to a file in a subrepo to hg forget.
2011-11-10 04:46:49 +04:00
$ echo c19 > s/f19
$ hg add s/f19
$ hg st -S
A s/f19
$ hg forget s/f19
forget: support forgetting explicit paths in subrepos Change the behavior of the forget command such that explicit paths in subrepos are handled by forgetting the file in the subrepo. This eliminates the previous behavior where if you called "hg forget" for an explicit path in a subrepo, it would state that the file is already untracked.
2011-11-10 04:46:51 +04:00
$ hg st -S
? s/f19
tests: add test for behavior of forget for explicit path in subrepo Adds a section to test-subrepo.t that demonstrates the current behavior when you pass the full path to a file in a subrepo to hg forget.
2011-11-10 04:46:49 +04:00
$ rm s/f19
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ cd ..
subrepo: allows to drop courtesy phase sync (issue3781) Publishing server may contains draft changeset when they are created locally. As publishing is the default, it is actually fairly common. Because of this "inconsistency" phases synchronization may be done even to publishing server. This may cause severe issues for subrepo. It is possible to reference read-only repository as subrepo. Push in a super repo recursively push subrepo. Those pushes to potential read only repo are not optional, they are "suffered" not "choosed". This does not break because as the repo is untouched the push is supposed to be empty. If the reference repo locally contains draft changesets, a courtesy push is triggered to turn them public. As the repo is read only, the push fails (after possible prompt asking for credential). Failure of the sub-push aborts the whole subrepo push. This force the user to define a custom default-push for such subrepo. This changeset introduce a prevention of this error client side by skipping the courtesy phase synchronisation in problematic situation. The phases synchronisation is skipped when four conditions are gathered: - this is a subrepo push, (normal push to read-only repo) - and remote support phase - and remote is publishing - and no changesets was pushed (if we pushed changesets, repo is not read only) The internal config option used in this version is not definitive. It is here to demonstrate a working fix to the issue. In the future we probably wants to track subrepo changes and avoid pushing to untouched one. That will prevent any attempt to push to read-only or unreachable subrepo. Another fix to prevent courtesy push from older clients to push to newer server is also still needed.
2013-01-31 04:44:29 +04:00
Courtesy phases synchronisation to publishing server does not block the push
(issue3781)
$ cp -r main issue3781
$ cp -r main issue3781-dest
$ cd issue3781-dest/s
$ hg phase tip # show we have draft changeset
5: draft
$ chmod a-w .hg/store/phaseroots # prevent phase push
$ cd ../../issue3781
$ cat >> .hg/hgrc << EOF
> [paths]
> default=../issue3781-dest/
> EOF
$ hg push
tests: fix windows test failure in test-subrepo.t
2013-02-05 02:41:11 +04:00
pushing to $TESTTMP/issue3781-dest (glob)
subrepo: allows to drop courtesy phase sync (issue3781) Publishing server may contains draft changeset when they are created locally. As publishing is the default, it is actually fairly common. Because of this "inconsistency" phases synchronization may be done even to publishing server. This may cause severe issues for subrepo. It is possible to reference read-only repository as subrepo. Push in a super repo recursively push subrepo. Those pushes to potential read only repo are not optional, they are "suffered" not "choosed". This does not break because as the repo is untouched the push is supposed to be empty. If the reference repo locally contains draft changesets, a courtesy push is triggered to turn them public. As the repo is read only, the push fails (after possible prompt asking for credential). Failure of the sub-push aborts the whole subrepo push. This force the user to define a custom default-push for such subrepo. This changeset introduce a prevention of this error client side by skipping the courtesy phase synchronisation in problematic situation. The phases synchronisation is skipped when four conditions are gathered: - this is a subrepo push, (normal push to read-only repo) - and remote support phase - and remote is publishing - and no changesets was pushed (if we pushed changesets, repo is not read only) The internal config option used in this version is not definitive. It is here to demonstrate a working fix to the issue. In the future we probably wants to track subrepo changes and avoid pushing to untouched one. That will prevent any attempt to push to read-only or unreachable subrepo. Another fix to prevent courtesy push from older clients to push to newer server is also still needed.
2013-01-31 04:44:29 +04:00
pushing subrepo s to $TESTTMP/issue3781-dest/s
searching for changes
no changes found
searching for changes
no changes found
[1]
subrepo: check phase of state in each subrepositories before committing Before this patch, phase of newly created commit is determined by "phases.new-commit" configuration regardless of phase of state in each subrepositories. For example, this may cause the "public" revision in the parent repository referring the "secret" one in subrepository. This patch checks phase of state in each subrepositories before committing in the parent, and aborts or changes phase of newly created commit if subrepositories have more restricted phase than the parent. This patch uses "follow" as default value of "phases.checksubrepos" configuration, because it can keep consistency between phases of the parent and subrepositories without breaking existing tool chains.
2013-11-13 10:55:30 +04:00
$ cd ..
Test phase choice for newly created commit with "phases.subrepochecks"
configuration
$ cd t
$ hg update -q -r 12
$ cat >> s/ss/.hg/hgrc <<EOF
> [phases]
> new-commit = secret
> EOF
$ cat >> s/.hg/hgrc <<EOF
> [phases]
> new-commit = draft
> EOF
$ echo phasecheck1 >> s/ss/a
$ hg -R s commit -S --config phases.checksubrepos=abort -m phasecheck1
committing subrepository ss
transaction abort!
rollback completed
abort: can't commit in draft phase conflicting secret from subrepository ss
[255]
$ echo phasecheck2 >> s/ss/a
$ hg -R s commit -S --config phases.checksubrepos=ignore -m phasecheck2
committing subrepository ss
$ hg -R s/ss phase tip
3: secret
$ hg -R s phase tip
6: draft
$ echo phasecheck3 >> s/ss/a
$ hg -R s commit -S -m phasecheck3
committing subrepository ss
warning: changes are committed in secret phase from subrepository ss
$ hg -R s/ss phase tip
4: secret
$ hg -R s phase tip
7: secret
$ cat >> t/.hg/hgrc <<EOF
> [phases]
> new-commit = draft
> EOF
$ cat >> .hg/hgrc <<EOF
> [phases]
> new-commit = public
> EOF
$ echo phasecheck4 >> s/ss/a
$ echo phasecheck4 >> t/t
$ hg commit -S -m phasecheck4
committing subrepository s
committing subrepository s/ss
warning: changes are committed in secret phase from subrepository ss
committing subrepository t
warning: changes are committed in secret phase from subrepository s
created new head
$ hg -R s/ss phase tip
5: secret
$ hg -R s phase tip
8: secret
$ hg -R t phase tip
6: draft
$ hg phase tip
15: secret
subrepo: allows to drop courtesy phase sync (issue3781) Publishing server may contains draft changeset when they are created locally. As publishing is the default, it is actually fairly common. Because of this "inconsistency" phases synchronization may be done even to publishing server. This may cause severe issues for subrepo. It is possible to reference read-only repository as subrepo. Push in a super repo recursively push subrepo. Those pushes to potential read only repo are not optional, they are "suffered" not "choosed". This does not break because as the repo is untouched the push is supposed to be empty. If the reference repo locally contains draft changesets, a courtesy push is triggered to turn them public. As the repo is read only, the push fails (after possible prompt asking for credential). Failure of the sub-push aborts the whole subrepo push. This force the user to define a custom default-push for such subrepo. This changeset introduce a prevention of this error client side by skipping the courtesy phase synchronisation in problematic situation. The phases synchronisation is skipped when four conditions are gathered: - this is a subrepo push, (normal push to read-only repo) - and remote support phase - and remote is publishing - and no changesets was pushed (if we pushed changesets, repo is not read only) The internal config option used in this version is not definitive. It is here to demonstrate a working fix to the issue. In the future we probably wants to track subrepo changes and avoid pushing to untouched one. That will prevent any attempt to push to read-only or unreachable subrepo. Another fix to prevent courtesy push from older clients to push to newer server is also still needed.
2013-01-31 04:44:29 +04:00
subrepo: check phase of state in each subrepositories before committing Before this patch, phase of newly created commit is determined by "phases.new-commit" configuration regardless of phase of state in each subrepositories. For example, this may cause the "public" revision in the parent repository referring the "secret" one in subrepository. This patch checks phase of state in each subrepositories before committing in the parent, and aborts or changes phase of newly created commit if subrepositories have more restricted phase than the parent. This patch uses "follow" as default value of "phases.checksubrepos" configuration, because it can keep consistency between phases of the parent and subrepositories without breaking existing tool chains.
2013-11-13 10:55:30 +04:00
$ cd ..
Reference in New Issue Copy Permalink