facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 23:38:50 +03:00
Code Issues Projects Releases Wiki Activity
f7b7fe9dcb
sapling/tests/test-mq-subrepo.t

621 lines
15 KiB
Perl
Raw Normal View History

tests: write hgrc of more than two lines by using shell heredoc Here document should be readable than repeating echo commands.
2014-11-04 17:41:46 +03:00
$ cat <<EOF >> $HGRCPATH
> [ui]
> commitsubrepos = Yes
> [extensions]
> mq =
> record =
> [diff]
> nodates = 1
> EOF
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
$ stdin=`pwd`/stdin.tmp
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
fn to create new repository w/dirty subrepo, and cd into it
$ mkrepo() {
> hg init $1
> cd $1
> hg qinit
> }
fn to create dirty subrepo
$ mksubrepo() {
> hg init $1
> cd $1
> echo a > a
> hg add
> cd ..
> }
$ testadd() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub
> echo sub = sub >> .hgsub
> hg add .hgsub
> echo % abort when adding .hgsub w/dirty subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo [$?]
> hg -R sub ci -m0sub
> echo % update substate when adding .hgsub w/clean updated subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> hg debugsub
> }
$ testmod() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub2
> echo sub2 = sub2 >> .hgsub
> echo % abort when modifying .hgsub w/dirty subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo [$?]
> hg -R sub2 ci -m0sub2
> echo % update substate when modifying .hgsub w/clean updated subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> hg debugsub
> }
$ testrm1() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub3
> echo sub3 = sub3 >> .hgsub
> hg ci -Aqmsub3
> $EXTRA
> echo b >> sub3/a
> hg rm .hgsub
> echo % update substate when removing .hgsub w/dirty subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo % debugsub should be empty
> hg debugsub
> }
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ testrm2() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub4
> echo sub4 = sub4 >> .hgsub
> hg ci -Aqmsub4
> $EXTRA
> hg rm .hgsub
> echo % update substate when removing .hgsub w/clean updated subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo % debugsub should be empty
> hg debugsub
> }
handle subrepos safely on qnew
$ mkrepo repo-2499-qnew
qnew: omit meaningless and harmful putting subrepositories into target list Before this patch, qnew puts updated subrepositories into target list forcibly, if any of -I, -X or patterns are specified. But this is meaningless and harmful, because: - putting subrepositories into target list doesn't affect the result of "localrepository.status()" "dirstate.status()" invoked via "localrepository.status()" always omits subrepositories from the result of it - any -I/-X opts and empty "pats" causes unexpected failure when any -I/-X opts are specified, "inclsubs" are always added to "pats", even if "pats" is empty. but this changes meaning of "pats" from "including all to be included" to "including only listed subrepositories" this may exclude ".hgsub" and cause unexpected exception raising ("can't commit subrepos without .hgsub" ). - qnew at other than repository root (with -I, -X or any patterns) causes unexpected failure "scmutil.match()" treats pattern without syntax type as 'relpath' type (= one rooted at cwd). but qnew puts subrepository paths rooted at the repository root, and it causes unexpected exception raising ("SUBREPO not under root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at other than repository root with -I, -X or any patterns. This patch omits meaningless and harmful putting subrepositories into target list. This omitting doesn't miss including updated subrepositories, because subrepositories are specified to "scmutil.matchfiles()" directly, to get "match" object for "localrepository.commit()".
2014-03-19 19:10:45 +04:00
$ testadd qnew -X path:no-effect -m0 0.diff
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
adding a
% abort when adding .hgsub w/dirty subrepo
A .hgsub
A sub/a
qnew: omit meaningless and harmful putting subrepositories into target list Before this patch, qnew puts updated subrepositories into target list forcibly, if any of -I, -X or patterns are specified. But this is meaningless and harmful, because: - putting subrepositories into target list doesn't affect the result of "localrepository.status()" "dirstate.status()" invoked via "localrepository.status()" always omits subrepositories from the result of it - any -I/-X opts and empty "pats" causes unexpected failure when any -I/-X opts are specified, "inclsubs" are always added to "pats", even if "pats" is empty. but this changes meaning of "pats" from "including all to be included" to "including only listed subrepositories" this may exclude ".hgsub" and cause unexpected exception raising ("can't commit subrepos without .hgsub" ). - qnew at other than repository root (with -I, -X or any patterns) causes unexpected failure "scmutil.match()" treats pattern without syntax type as 'relpath' type (= one rooted at cwd). but qnew puts subrepository paths rooted at the repository root, and it causes unexpected exception raising ("SUBREPO not under root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at other than repository root with -I, -X or any patterns. This patch omits meaningless and harmful putting subrepositories into target list. This omitting doesn't miss including updated subrepositories, because subrepositories are specified to "scmutil.matchfiles()" directly, to get "match" object for "localrepository.commit()".
2014-03-19 19:10:45 +04:00
% qnew -X path:no-effect -m0 0.diff
subrepo: add bailifchanged to centralize raising Abort if subrepo is dirty This patch also centralizes composing dirty reason message like "uncommitted changes in subrepository 'xxxx'".
2015-03-25 07:55:35 +03:00
abort: uncommitted changes in subrepository 'sub'
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
[255]
% update substate when adding .hgsub w/clean updated subrepo
A .hgsub
qnew: omit meaningless and harmful putting subrepositories into target list Before this patch, qnew puts updated subrepositories into target list forcibly, if any of -I, -X or patterns are specified. But this is meaningless and harmful, because: - putting subrepositories into target list doesn't affect the result of "localrepository.status()" "dirstate.status()" invoked via "localrepository.status()" always omits subrepositories from the result of it - any -I/-X opts and empty "pats" causes unexpected failure when any -I/-X opts are specified, "inclsubs" are always added to "pats", even if "pats" is empty. but this changes meaning of "pats" from "including all to be included" to "including only listed subrepositories" this may exclude ".hgsub" and cause unexpected exception raising ("can't commit subrepos without .hgsub" ). - qnew at other than repository root (with -I, -X or any patterns) causes unexpected failure "scmutil.match()" treats pattern without syntax type as 'relpath' type (= one rooted at cwd). but qnew puts subrepository paths rooted at the repository root, and it causes unexpected exception raising ("SUBREPO not under root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at other than repository root with -I, -X or any patterns. This patch omits meaningless and harmful putting subrepositories into target list. This omitting doesn't miss including updated subrepositories, because subrepositories are specified to "scmutil.matchfiles()" directly, to get "match" object for "localrepository.commit()".
2014-03-19 19:10:45 +04:00
% qnew -X path:no-effect -m0 0.diff
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
qnew: omit meaningless and harmful putting subrepositories into target list Before this patch, qnew puts updated subrepositories into target list forcibly, if any of -I, -X or patterns are specified. But this is meaningless and harmful, because: - putting subrepositories into target list doesn't affect the result of "localrepository.status()" "dirstate.status()" invoked via "localrepository.status()" always omits subrepositories from the result of it - any -I/-X opts and empty "pats" causes unexpected failure when any -I/-X opts are specified, "inclsubs" are always added to "pats", even if "pats" is empty. but this changes meaning of "pats" from "including all to be included" to "including only listed subrepositories" this may exclude ".hgsub" and cause unexpected exception raising ("can't commit subrepos without .hgsub" ). - qnew at other than repository root (with -I, -X or any patterns) causes unexpected failure "scmutil.match()" treats pattern without syntax type as 'relpath' type (= one rooted at cwd). but qnew puts subrepository paths rooted at the repository root, and it causes unexpected exception raising ("SUBREPO not under root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at other than repository root with -I, -X or any patterns. This patch omits meaningless and harmful putting subrepositories into target list. This omitting doesn't miss including updated subrepositories, because subrepositories are specified to "scmutil.matchfiles()" directly, to get "match" object for "localrepository.commit()".
2014-03-19 19:10:45 +04:00
$ testmod qnew --cwd .. -R repo-2499-qnew -X path:no-effect -m1 1.diff
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
adding a
% abort when modifying .hgsub w/dirty subrepo
M .hgsub
A sub2/a
qnew: omit meaningless and harmful putting subrepositories into target list Before this patch, qnew puts updated subrepositories into target list forcibly, if any of -I, -X or patterns are specified. But this is meaningless and harmful, because: - putting subrepositories into target list doesn't affect the result of "localrepository.status()" "dirstate.status()" invoked via "localrepository.status()" always omits subrepositories from the result of it - any -I/-X opts and empty "pats" causes unexpected failure when any -I/-X opts are specified, "inclsubs" are always added to "pats", even if "pats" is empty. but this changes meaning of "pats" from "including all to be included" to "including only listed subrepositories" this may exclude ".hgsub" and cause unexpected exception raising ("can't commit subrepos without .hgsub" ). - qnew at other than repository root (with -I, -X or any patterns) causes unexpected failure "scmutil.match()" treats pattern without syntax type as 'relpath' type (= one rooted at cwd). but qnew puts subrepository paths rooted at the repository root, and it causes unexpected exception raising ("SUBREPO not under root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at other than repository root with -I, -X or any patterns. This patch omits meaningless and harmful putting subrepositories into target list. This omitting doesn't miss including updated subrepositories, because subrepositories are specified to "scmutil.matchfiles()" directly, to get "match" object for "localrepository.commit()".
2014-03-19 19:10:45 +04:00
% qnew --cwd .. -R repo-2499-qnew -X path:no-effect -m1 1.diff
subrepo: add bailifchanged to centralize raising Abort if subrepo is dirty This patch also centralizes composing dirty reason message like "uncommitted changes in subrepository 'xxxx'".
2015-03-25 07:55:35 +03:00
abort: uncommitted changes in subrepository 'sub2'
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
[255]
% update substate when modifying .hgsub w/clean updated subrepo
M .hgsub
qnew: omit meaningless and harmful putting subrepositories into target list Before this patch, qnew puts updated subrepositories into target list forcibly, if any of -I, -X or patterns are specified. But this is meaningless and harmful, because: - putting subrepositories into target list doesn't affect the result of "localrepository.status()" "dirstate.status()" invoked via "localrepository.status()" always omits subrepositories from the result of it - any -I/-X opts and empty "pats" causes unexpected failure when any -I/-X opts are specified, "inclsubs" are always added to "pats", even if "pats" is empty. but this changes meaning of "pats" from "including all to be included" to "including only listed subrepositories" this may exclude ".hgsub" and cause unexpected exception raising ("can't commit subrepos without .hgsub" ). - qnew at other than repository root (with -I, -X or any patterns) causes unexpected failure "scmutil.match()" treats pattern without syntax type as 'relpath' type (= one rooted at cwd). but qnew puts subrepository paths rooted at the repository root, and it causes unexpected exception raising ("SUBREPO not under root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at other than repository root with -I, -X or any patterns. This patch omits meaningless and harmful putting subrepositories into target list. This omitting doesn't miss including updated subrepositories, because subrepositories are specified to "scmutil.matchfiles()" directly, to get "match" object for "localrepository.commit()".
2014-03-19 19:10:45 +04:00
% qnew --cwd .. -R repo-2499-qnew -X path:no-effect -m1 1.diff
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
path sub2
source sub2
revision 1f94c7611cc6b74f5a17b16121a1170d44776845
$ hg qpop -qa
patch queue now empty
$ testrm1 qnew -m2 2.diff
adding a
% update substate when removing .hgsub w/dirty subrepo
M sub3/a
R .hgsub
% qnew -m2 2.diff
% debugsub should be empty
$ hg qpop -qa
patch queue now empty
$ testrm2 qnew -m3 3.diff
adding a
% update substate when removing .hgsub w/clean updated subrepo
R .hgsub
% qnew -m3 3.diff
% debugsub should be empty
$ cd ..
handle subrepos safely on qrefresh
$ mkrepo repo-2499-qrefresh
$ hg qnew -m0 0.diff
$ testadd qrefresh
adding a
% abort when adding .hgsub w/dirty subrepo
A .hgsub
A sub/a
% qrefresh
subrepo: add bailifchanged to centralize raising Abort if subrepo is dirty This patch also centralizes composing dirty reason message like "uncommitted changes in subrepository 'xxxx'".
2015-03-25 07:55:35 +03:00
abort: uncommitted changes in subrepository 'sub'
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
[255]
% update substate when adding .hgsub w/clean updated subrepo
A .hgsub
% qrefresh
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
$ hg qnew -m1 1.diff
$ testmod qrefresh
adding a
% abort when modifying .hgsub w/dirty subrepo
M .hgsub
A sub2/a
% qrefresh
subrepo: add bailifchanged to centralize raising Abort if subrepo is dirty This patch also centralizes composing dirty reason message like "uncommitted changes in subrepository 'xxxx'".
2015-03-25 07:55:35 +03:00
abort: uncommitted changes in subrepository 'sub2'
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
[255]
% update substate when modifying .hgsub w/clean updated subrepo
M .hgsub
% qrefresh
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
path sub2
source sub2
revision 1f94c7611cc6b74f5a17b16121a1170d44776845
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ EXTRA='hg qnew -m2 2.diff'
$ testrm1 qrefresh
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
adding a
% update substate when removing .hgsub w/dirty subrepo
M sub3/a
R .hgsub
% qrefresh
% debugsub should be empty
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ EXTRA='hg qnew -m3 3.diff'
$ testrm2 qrefresh
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
adding a
% update substate when removing .hgsub w/clean updated subrepo
R .hgsub
% qrefresh
% debugsub should be empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ EXTRA=
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ cd ..
handle subrepos safely on qpush/qpop
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
(and we cannot qpop / qpush with a modified subrepo)
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ mkrepo repo-2499-qpush
$ mksubrepo sub
adding a
$ hg -R sub ci -m0sub
$ echo sub = sub > .hgsub
$ hg add .hgsub
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
$ hg commit -m0
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ hg debugsub
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
$ echo foo > ./sub/a
$ hg -R sub commit -m foo
$ hg commit -m1
$ hg qimport -r "0:tip"
mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1376350710 -7200 # Tue Aug 13 01:38:30 2013 +0200 # Node ID 60897e264858cdcd46f89e27a702086f08adca02 # Parent 2defb5453f223c3027eb2f7788fbddd52bbb3352 mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions).
2013-08-13 03:38:30 +04:00
$ hg -R sub id --id
aa037b301eba
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
qpop
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
$ hg -R sub update 0000
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ hg qpop
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
abort: local changed subrepos found, refresh first
[255]
$ hg revert sub
reverting subrepo sub
tests: fix globs for Windows test-largefiles-update.t, test-subrepo.t, test-tag.t, and test-rename-dir-merge.t still warn about no result returned because of unnecessary globs that test-check-code-hg.t wants, relating to output for pushing to, pulling from and moving X to Y.
2014-11-17 00:26:15 +03:00
adding sub/a (glob)
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
$ hg qpop
popping 1.diff
now at: 0.diff
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ hg status -AS
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
C .hgsub
C .hgsubstate
mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1376350710 -7200 # Tue Aug 13 01:38:30 2013 +0200 # Node ID 60897e264858cdcd46f89e27a702086f08adca02 # Parent 2defb5453f223c3027eb2f7788fbddd52bbb3352 mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions).
2013-08-13 03:38:30 +04:00
C sub/a
$ hg -R sub id --id
b2fdb12cd82b
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
qpush
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
$ hg -R sub update 0000
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ hg qpush
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
abort: local changed subrepos found, refresh first
[255]
$ hg revert sub
reverting subrepo sub
tests: fix globs for Windows test-largefiles-update.t, test-subrepo.t, test-tag.t, and test-rename-dir-merge.t still warn about no result returned because of unnecessary globs that test-check-code-hg.t wants, relating to output for pushing to, pulling from and moving X to Y.
2014-11-17 00:26:15 +03:00
adding sub/a (glob)
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
$ hg qpush
applying 1.diff
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 sub diverged (local revision: b2fdb12cd82b, remote revision: aa037b301eba)
(M)erge, keep (l)ocal or keep (r)emote? m
mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1376350710 -7200 # Tue Aug 13 01:38:30 2013 +0200 # Node ID 60897e264858cdcd46f89e27a702086f08adca02 # Parent 2defb5453f223c3027eb2f7788fbddd52bbb3352 mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions).
2013-08-13 03:38:30 +04:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check. # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1375742979 -7200 # Tue Aug 06 00:49:39 2013 +0200 # Node ID a5c90acff5e61aae714ba6c9457d766c54b4f124 # Parent bacc55ce64d5de9d1eb7fcefccd3829161d5dcf7 mq: look for modified subrepos when checking for local changes It was possible to apply, unapply, fold, patches (etc) with modified subrepos, which resulted in surprising behavior. For example it was easy to apply a patch with a modified subrepo, and then the refresh it and accidentally end up including the modified subrepo on the refreshed patch. A test has been added to verify this new check.
2013-08-06 02:49:39 +04:00
now at: 1.diff
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ hg status -AS
C .hgsub
mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1376350710 -7200 # Tue Aug 13 01:38:30 2013 +0200 # Node ID 60897e264858cdcd46f89e27a702086f08adca02 # Parent 2defb5453f223c3027eb2f7788fbddd52bbb3352 mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions).
2013-08-13 03:38:30 +04:00
C .hgsubstate
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
C sub/a
mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1376350710 -7200 # Tue Aug 13 01:38:30 2013 +0200 # Node ID 60897e264858cdcd46f89e27a702086f08adca02 # Parent 2defb5453f223c3027eb2f7788fbddd52bbb3352 mq: update subrepos when applying / unapplying patches that change .hgsubstate Up until now applying or unapplying a patch that modified .hgsubstate would not work as expected because it would not update the subrepos according to the .hgsubstate change. This made it very easy to lose subrepo changes when using mq. This revision also changes the test-mq-subrepo test so that on the qpop / qpush tests. We no longer use the debugsub command to check the state of the subrepos after the qpop and qpush operations. Instead we directly run the id command on the subrepos that we want to check. The reason is that using the debugsub command is misleading because it does not really check the state of the subrepos on the working directory (it just returns what the change that is specified on a given revision). Because of this the tests did not detect the problem that this revision fixes (i.e. that applying a patch did not update the subrepos to the corresponding revisions).
2013-08-13 03:38:30 +04:00
$ hg -R sub id --id
aa037b301eba
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ cd ..
handle subrepos safely on qrecord
$ mkrepo repo-2499-qrecord
$ testadd qrecord --config ui.interactive=1 -m0 0.diff <<EOF
> y
> y
> EOF
adding a
% abort when adding .hgsub w/dirty subrepo
A .hgsub
A sub/a
% qrecord --config ui.interactive=1 -m0 0.diff
diff --git a/.hgsub b/.hgsub
new file mode 100644
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
examine changes to '.hgsub'? [Ynesfdaq?] y
record: allow editing new files (issue4304) While using the record extension to select changes, the user couldn't see the content of newly added files and had to select/reject them based on filename. The test is changed accordingly in two places.
2015-03-07 02:57:43 +03:00
@@ -0,0 +1,1 @@
+sub = sub
record this change to '.hgsub'? [Ynesfdaq?] y
subrepo: precisely identify the missing subrepo spec file It isn't obvious which file is the problem with deep subrepos, so provide the path. Since the parsing is done with a ctx and not a subrepo object, it isn't possible to display a path from the root subrepo. Therefore, the path shown is relative to cwd. There's no test coverage for the first abort, and I couldn't figure out how to trigger it, but it is changed for consistency.
2015-04-05 22:08:55 +03:00
warning: subrepo spec file '.hgsub' not found
subrepo: add bailifchanged to centralize raising Abort if subrepo is dirty This patch also centralizes composing dirty reason message like "uncommitted changes in subrepository 'xxxx'".
2015-03-25 07:55:35 +03:00
abort: uncommitted changes in subrepository 'sub'
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
[255]
% update substate when adding .hgsub w/clean updated subrepo
A .hgsub
% qrecord --config ui.interactive=1 -m0 0.diff
diff --git a/.hgsub b/.hgsub
new file mode 100644
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
examine changes to '.hgsub'? [Ynesfdaq?] y
record: allow editing new files (issue4304) While using the record extension to select changes, the user couldn't see the content of newly added files and had to select/reject them based on filename. The test is changed accordingly in two places.
2015-03-07 02:57:43 +03:00
@@ -0,0 +1,1 @@
+sub = sub
record this change to '.hgsub'? [Ynesfdaq?] y
subrepo: precisely identify the missing subrepo spec file It isn't obvious which file is the problem with deep subrepos, so provide the path. Since the parsing is done with a ctx and not a subrepo object, it isn't possible to display a path from the root subrepo. Therefore, the path shown is relative to cwd. There's no test coverage for the first abort, and I couldn't figure out how to trigger it, but it is changed for consistency.
2015-04-05 22:08:55 +03:00
warning: subrepo spec file '.hgsub' not found
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
$ testmod qrecord --config ui.interactive=1 -m1 1.diff <<EOF
> y
> y
> EOF
adding a
% abort when modifying .hgsub w/dirty subrepo
M .hgsub
A sub2/a
% qrecord --config ui.interactive=1 -m1 1.diff
diff --git a/.hgsub b/.hgsub
1 hunks, 1 lines changed
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
examine changes to '.hgsub'? [Ynesfdaq?] y
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
@@ -1,1 +1,2 @@
sub = sub
+sub2 = sub2
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
record this change to '.hgsub'? [Ynesfdaq?] y
subrepo: add bailifchanged to centralize raising Abort if subrepo is dirty This patch also centralizes composing dirty reason message like "uncommitted changes in subrepository 'xxxx'".
2015-03-25 07:55:35 +03:00
abort: uncommitted changes in subrepository 'sub2'
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
[255]
% update substate when modifying .hgsub w/clean updated subrepo
M .hgsub
% qrecord --config ui.interactive=1 -m1 1.diff
diff --git a/.hgsub b/.hgsub
1 hunks, 1 lines changed
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
examine changes to '.hgsub'? [Ynesfdaq?] y
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
@@ -1,1 +1,2 @@
sub = sub
+sub2 = sub2
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
record this change to '.hgsub'? [Ynesfdaq?] y
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
path sub2
source sub2
revision 1f94c7611cc6b74f5a17b16121a1170d44776845
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ testrm1 qrecord --config ui.interactive=1 -m2 2.diff <<EOF
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> y
> y
> EOF
adding a
% update substate when removing .hgsub w/dirty subrepo
M sub3/a
R .hgsub
% qrecord --config ui.interactive=1 -m2 2.diff
diff --git a/.hgsub b/.hgsub
deleted file mode 100644
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
examine changes to '.hgsub'? [Ynesfdaq?] y
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
% debugsub should be empty
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ testrm2 qrecord --config ui.interactive=1 -m3 3.diff <<EOF
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> y
> y
> EOF
adding a
% update substate when removing .hgsub w/clean updated subrepo
R .hgsub
% qrecord --config ui.interactive=1 -m3 3.diff
diff --git a/.hgsub b/.hgsub
deleted file mode 100644
ui: show prompt choice if input is not a tty but is forced to be interactive The tests often set ui.interactive to control normally interactive prompts from stdin. That gave an output where it was non-obvious what prompts got which which response, and the output lacked the newline users would see after input. Instead, if the input not is a tty, write the selection and a newline.
2014-10-01 03:04:18 +04:00
examine changes to '.hgsub'? [Ynesfdaq?] y
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
% debugsub should be empty
$ cd ..
subrepo: don't commit in subrepo if it's clean If a subrepo has changed relative to the outer repo's substate, but the subrepo itself is clean, we don't need to commit in the subrepo.
2011-07-19 22:43:53 +04:00
correctly handle subrepos with patch queues
$ mkrepo repo-subrepo-with-queue
$ mksubrepo sub
adding a
$ hg -R sub qnew sub0.diff
$ echo sub = sub >> .hgsub
$ hg add .hgsub
$ hg qnew 0.diff
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
$ cd ..
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
check whether MQ operations can import updated .hgsubstate correctly
both into 'revision' and 'patch file under .hg/patches':
$ hg init importing-hgsubstate
$ cd importing-hgsubstate
$ echo a > a
$ hg commit -u test -d '0 0' -Am '#0 in parent'
adding a
$ hg init sub
$ echo sa > sub/sa
$ hg -R sub commit -u test -d '0 0' -Am '#0 in sub'
adding sa
$ echo 'sub = sub' > .hgsub
$ touch .hgsubstate
$ hg add .hgsub .hgsubstate
$ hg qnew -u test -d '0 0' import-at-qnew
$ hg -R sub parents --template '{node} sub\n'
b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
$ cat .hgsubstate
b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
$ hg diff -c tip
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
diff -r f499373e340c -r f69e96d86e75 .hgsub
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
--- /dev/null
+++ b/.hgsub
@@ -0,0 +1,1 @@
+sub = sub
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
diff -r f499373e340c -r f69e96d86e75 .hgsubstate
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
--- /dev/null
+++ b/.hgsubstate
@@ -0,0 +1,1 @@
+b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
$ cat .hg/patches/import-at-qnew
# HG changeset patch
# User test
# Date 0 0
mq: write '# Parent ' lines with two spaces like export does (BC) This aligns "Parent" node IDs with "Node ID" node IDs.
2014-09-24 03:36:44 +04:00
# Parent f499373e340cdca5d01dee904aeb42dd2a325e71
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
diff -r f499373e340c -r f69e96d86e75 .hgsub
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
--- /dev/null
+++ b/.hgsub
@@ -0,0 +1,1 @@
+sub = sub
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
diff -r f499373e340c -r f69e96d86e75 .hgsubstate
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
--- /dev/null
+++ b/.hgsubstate
@@ -0,0 +1,1 @@
+b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
$ hg parents --template '{node}\n'
f69e96d86e75a6d4fd88285dc9697acb23951041
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsub .hgsubstate
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
check also whether qnew not including ".hgsubstate" explicitly causes
as same result (in node hash) as one including it.
$ hg qpop -a -q
patch queue now empty
$ hg qdelete import-at-qnew
$ echo 'sub = sub' > .hgsub
$ hg add .hgsub
$ rm -f .hgsubstate
$ hg qnew -u test -d '0 0' import-at-qnew
$ hg parents --template '{node}\n'
f69e96d86e75a6d4fd88285dc9697acb23951041
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsub .hgsubstate
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
check whether qrefresh imports updated .hgsubstate correctly
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
$ hg qpop
popping import-at-qnew
patch queue now empty
$ hg qpush
applying import-at-qnew
now at: import-at-qnew
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsub .hgsubstate
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
mq: create patch file after commit to import diff of ".hgsubstate" at qrefresh Even though the committed revision contains diff of ".hgsubstate", the patch file created by qrefresh doesn't contain it, because: - ".hgsubstate" is not listed up as one of target files of the patch for reasons below, so diff of ".hgsubstate" is not imported into patch file - status of ".hgsubstate" in working directory is usually "clean" - ".hgsubstate" is not specified explicitly by users - the patch file is created before commit processing which updates or creates ".hgsubstate" automatically, so there is no diff for it at that time This patch resolves this problem by: - putting ".hgsubstate" into target list of the patch, if needed: this allows "patch.diff()" to import diff of ".hgsubstate" into patch file. - creating the patch file after commit processing: this updates ".hgsubstate" before "patch.diff()" invocation. For the former fixing, this patch introduces "putsubstate2changes()" to share same implementation with qnew. This is invoked only once per qnew/qrefresh at most, so there is less performance impact. This patch also omits "match" argument for "patch.diff()" invocation, because "patch.diff()" ignores "match" if "changes" is specified.
2012-06-27 17:03:27 +04:00
$ hg qnew import-at-qrefresh
$ echo sb > sub/sb
$ hg -R sub commit -u test -d '0 0' -Am '#1 in sub'
adding sb
$ hg qrefresh -u test -d '0 0'
$ hg -R sub parents --template '{node} sub\n'
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hgsubstate
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ hg diff -c tip
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
diff -r 05b056bb9c8c -r d987bec230f4 .hgsubstate
mq: create patch file after commit to import diff of ".hgsubstate" at qrefresh Even though the committed revision contains diff of ".hgsubstate", the patch file created by qrefresh doesn't contain it, because: - ".hgsubstate" is not listed up as one of target files of the patch for reasons below, so diff of ".hgsubstate" is not imported into patch file - status of ".hgsubstate" in working directory is usually "clean" - ".hgsubstate" is not specified explicitly by users - the patch file is created before commit processing which updates or creates ".hgsubstate" automatically, so there is no diff for it at that time This patch resolves this problem by: - putting ".hgsubstate" into target list of the patch, if needed: this allows "patch.diff()" to import diff of ".hgsubstate" into patch file. - creating the patch file after commit processing: this updates ".hgsubstate" before "patch.diff()" invocation. For the former fixing, this patch introduces "putsubstate2changes()" to share same implementation with qnew. This is invoked only once per qnew/qrefresh at most, so there is less performance impact. This patch also omits "match" argument for "patch.diff()" invocation, because "patch.diff()" ignores "match" if "changes" is specified.
2012-06-27 17:03:27 +04:00
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hg/patches/import-at-qrefresh
# HG changeset patch
# User test
mq: refactor patchheader header ordering to match export (BC) The refactoring also gives more robust and extendable handling of other HG headers.
2014-09-24 04:41:11 +04:00
# Date 0 0
mq: write '# Parent ' lines with two spaces like export does (BC) This aligns "Parent" node IDs with "Node ID" node IDs.
2014-09-24 03:36:44 +04:00
# Parent 05b056bb9c8c05ff15258b84fd42ab3527271033
mq: create patch file after commit to import diff of ".hgsubstate" at qrefresh Even though the committed revision contains diff of ".hgsubstate", the patch file created by qrefresh doesn't contain it, because: - ".hgsubstate" is not listed up as one of target files of the patch for reasons below, so diff of ".hgsubstate" is not imported into patch file - status of ".hgsubstate" in working directory is usually "clean" - ".hgsubstate" is not specified explicitly by users - the patch file is created before commit processing which updates or creates ".hgsubstate" automatically, so there is no diff for it at that time This patch resolves this problem by: - putting ".hgsubstate" into target list of the patch, if needed: this allows "patch.diff()" to import diff of ".hgsubstate" into patch file. - creating the patch file after commit processing: this updates ".hgsubstate" before "patch.diff()" invocation. For the former fixing, this patch introduces "putsubstate2changes()" to share same implementation with qnew. This is invoked only once per qnew/qrefresh at most, so there is less performance impact. This patch also omits "match" argument for "patch.diff()" invocation, because "patch.diff()" ignores "match" if "changes" is specified.
2012-06-27 17:03:27 +04:00
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
diff -r 05b056bb9c8c .hgsubstate
mq: create patch file after commit to import diff of ".hgsubstate" at qrefresh Even though the committed revision contains diff of ".hgsubstate", the patch file created by qrefresh doesn't contain it, because: - ".hgsubstate" is not listed up as one of target files of the patch for reasons below, so diff of ".hgsubstate" is not imported into patch file - status of ".hgsubstate" in working directory is usually "clean" - ".hgsubstate" is not specified explicitly by users - the patch file is created before commit processing which updates or creates ".hgsubstate" automatically, so there is no diff for it at that time This patch resolves this problem by: - putting ".hgsubstate" into target list of the patch, if needed: this allows "patch.diff()" to import diff of ".hgsubstate" into patch file. - creating the patch file after commit processing: this updates ".hgsubstate" before "patch.diff()" invocation. For the former fixing, this patch introduces "putsubstate2changes()" to share same implementation with qnew. This is invoked only once per qnew/qrefresh at most, so there is less performance impact. This patch also omits "match" argument for "patch.diff()" invocation, because "patch.diff()" ignores "match" if "changes" is specified.
2012-06-27 17:03:27 +04:00
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsubstate
mq: create patch file after commit to import diff of ".hgsubstate" at qrefresh Even though the committed revision contains diff of ".hgsubstate", the patch file created by qrefresh doesn't contain it, because: - ".hgsubstate" is not listed up as one of target files of the patch for reasons below, so diff of ".hgsubstate" is not imported into patch file - status of ".hgsubstate" in working directory is usually "clean" - ".hgsubstate" is not specified explicitly by users - the patch file is created before commit processing which updates or creates ".hgsubstate" automatically, so there is no diff for it at that time This patch resolves this problem by: - putting ".hgsubstate" into target list of the patch, if needed: this allows "patch.diff()" to import diff of ".hgsubstate" into patch file. - creating the patch file after commit processing: this updates ".hgsubstate" before "patch.diff()" invocation. For the former fixing, this patch introduces "putsubstate2changes()" to share same implementation with qnew. This is invoked only once per qnew/qrefresh at most, so there is less performance impact. This patch also omits "match" argument for "patch.diff()" invocation, because "patch.diff()" ignores "match" if "changes" is specified.
2012-06-27 17:03:27 +04:00
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
$ hg qrefresh -u test -d '0 0'
$ cat .hgsubstate
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ hg diff -c tip
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
diff -r 05b056bb9c8c -r d987bec230f4 .hgsubstate
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hg/patches/import-at-qrefresh
# HG changeset patch
# User test
mq: refactor patchheader header ordering to match export (BC) The refactoring also gives more robust and extendable handling of other HG headers.
2014-09-24 04:41:11 +04:00
# Date 0 0
mq: write '# Parent ' lines with two spaces like export does (BC) This aligns "Parent" node IDs with "Node ID" node IDs.
2014-09-24 03:36:44 +04:00
# Parent 05b056bb9c8c05ff15258b84fd42ab3527271033
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
diff -r 05b056bb9c8c .hgsubstate
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsubstate
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
$ hg update -C tip
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg qpop -a
popping import-at-qrefresh
popping import-at-qnew
patch queue now empty
$ hg -R sub update -C 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo 'sub = sub' > .hgsub
$ hg commit -Am '#1 in parent'
adding .hgsub
$ hg -R sub update -C 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Merge spelling fixes
2012-09-11 19:36:09 +04:00
$ hg commit -Am '#2 in parent (but will be rolled back soon)'
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
$ hg rollback
repository tip rolled back to revision 1 (undo commit)
working directory now based on revision 1
$ hg status
M .hgsubstate
$ hg qnew -u test -d '0 0' checkstate-at-qnew
$ hg -R sub parents --template '{node} sub\n'
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hgsubstate
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ hg diff -c tip
diff -r 4d91eb2fa1d1 -r 1259c112d884 .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hg/patches/checkstate-at-qnew
# HG changeset patch
# User test
# Date 0 0
mq: write '# Parent ' lines with two spaces like export does (BC) This aligns "Parent" node IDs with "Node ID" node IDs.
2014-09-24 03:36:44 +04:00
# Parent 4d91eb2fa1d1b22ec513347b9cd06f6b49d470fa
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
diff -r 4d91eb2fa1d1 -r 1259c112d884 .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsubstate
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
check whether qrefresh not including ".hgsubstate" explicitly causes
as same result (in node hash) as one including it.
$ hg update -C -q 0
$ hg qpop -a -q
patch queue now empty
$ hg qnew -u test -d '0 0' add-hgsub-at-qrefresh
$ echo 'sub = sub' > .hgsub
$ echo > .hgsubstate
$ hg add .hgsub .hgsubstate
$ hg qrefresh -u test -d '0 0'
$ hg parents --template '{node}\n'
7c48c35501aae6770ed9c2517014628615821a8e
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsub .hgsubstate
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
$ hg qpop -a -q
patch queue now empty
$ hg qdelete add-hgsub-at-qrefresh
$ hg qnew -u test -d '0 0' add-hgsub-at-qrefresh
$ echo 'sub = sub' > .hgsub
$ hg add .hgsub
$ rm -f .hgsubstate
$ hg qrefresh -u test -d '0 0'
$ hg parents --template '{node}\n'
7c48c35501aae6770ed9c2517014628615821a8e
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
2014-03-22 18:39:51 +04:00
$ hg parents --template '{files}\n'
.hgsub .hgsubstate
mq: omit ".hgsubstate" from qnew/qrefresh target list for consistent node hash Before this patch, even if specified file patterns and -I/-X options cause listing ".hgsubstate" up in the target list, qnew/qrefresh put ".hgsubstate" into the target list individually and forcibly. This changes how many times ".hgsubstate" appear in the target list according to run-time conditions, and causes inconsistent node hash, even though revision content is same, because node hash calculation uses the specified target list directly (without duplication check or so). This patch always omits ".hgsubstate" from qnew/qrefresh target list for consistent node hash. This omitting doesn't miss including ".hgsubstate" changes, because: - "localrepository.commit()" puts ".hgsubstate" into the target list for "commitctx()" forcibly if needed - "mq.putsubstate2changes()" puts ".hgsubstate" into the target list for "patch.diff()" if it is not yet listed up
2014-03-19 19:10:45 +04:00
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
$ cd ..
$ cd ..
Reference in New Issue Copy Permalink