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

684 lines
17 KiB
Perl
Raw Normal View History

tests: replace exit 80 with #require
2014-08-06 20:43:59 +04:00
#require svn15
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ SVNREPOPATH=`pwd`/svn-repo
#if windows
tests: use $PYTHON instead of hardcoding python This makes running the testsuite with pypy possible.
2014-10-15 23:35:59 +04:00
$ SVNREPOURL=file:///`$PYTHON -c "import urllib, sys; sys.stdout.write(urllib.quote(sys.argv[1]))" "$SVNREPOPATH"`
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
#else
tests: use $PYTHON instead of hardcoding python This makes running the testsuite with pypy possible.
2014-10-15 23:35:59 +04:00
$ SVNREPOURL=file://`$PYTHON -c "import urllib, sys; sys.stdout.write(urllib.quote(sys.argv[1]))" "$SVNREPOPATH"`
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
#endif
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
create subversion repo
$ WCROOT="`pwd`/svn-wc"
$ svnadmin create svn-repo
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn co "$SVNREPOURL" svn-wc
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
Checked out revision 0.
$ cd svn-wc
$ mkdir src
$ echo alpha > src/alpha
$ svn add src
A src
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
A src/alpha (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ mkdir externals
$ echo other > externals/other
$ svn add externals
A externals
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
A externals/other (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ svn ci -m 'Add alpha'
Adding externals
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
Adding externals/other (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
Adding src
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
Adding src/alpha (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
Transmitting file data ..
Committed revision 1.
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn up -q
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ echo "externals -r1 $SVNREPOURL/externals" > extdef
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ svn propset -F extdef svn:externals src
property 'svn:externals' set on 'src'
$ svn ci -m 'Setting externals'
Sending src
Committed revision 2.
$ cd ..
create hg repo
$ mkdir sub
$ cd sub
$ hg init t
$ cd t
first revision, no sub
$ echo a > a
$ hg ci -Am0
adding a
add first svn sub with leading whitespaces
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ echo "s = [svn] $SVNREPOURL/src" >> .hgsub
$ echo "subdir/s = [svn] $SVNREPOURL/src" >> .hgsub
$ svn co --quiet "$SVNREPOURL"/src s
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
$ mkdir subdir
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn co --quiet "$SVNREPOURL"/src subdir/s
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ hg add .hgsub
$ hg ci -m1
subrepo: fix status check on SVN subrepos (issue2445)
2010-10-21 12:28:51 +04:00
make sure we avoid empty commits (issue2445)
$ hg sum
parent: 1:* tip (glob)
1
branch: default
commit: (clean)
update: (current)
$ hg ci -moops
nothing changed
[1]
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
debugsub
tests: drop a bunch of sed calls from unified tests
2010-09-22 01:44:13 +04:00
$ hg debugsub
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
path s
test-subrepo-svn.t: ignore that subversion %-encodes $TESTTMP Use a glob instead of expecting $TESTTMP.
2010-10-10 00:06:22 +04:00
source file://*/svn-repo/src (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
revision 2
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
path subdir/s
source file://*/svn-repo/src (glob)
revision 2
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
change file in svn and hg, commit
$ echo a >> a
$ echo alpha >> s/alpha
subrepo: fix status check on SVN subrepos (issue2445)
2010-10-21 12:28:51 +04:00
$ hg sum
parent: 1:* tip (glob)
1
branch: default
commit: 1 modified, 1 subrepos
update: (current)
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ hg commit --subrepos -m 'Message!' | grep -v Updating
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
committing subrepository s
tests: various fixes for new unified test pattern format
2010-09-23 03:20:47 +04:00
Sending*s/alpha (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
Transmitting file data .
Committed revision 3.
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into '*s/externals'* (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
External at revision 1.
At revision 3.
tests: drop a bunch of sed calls from unified tests
2010-09-22 01:44:13 +04:00
$ hg debugsub
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
path s
test-subrepo-svn.t: ignore that subversion %-encodes $TESTTMP Use a glob instead of expecting $TESTTMP.
2010-10-10 00:06:22 +04:00
source file://*/svn-repo/src (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
revision 3
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
path subdir/s
source file://*/svn-repo/src (glob)
revision 2
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
subrepo/svn: abort on commit with missing file (issue3029) Previous code was printing a traceback because it expected some error output from svn. But sometimes our definition of "changed" differs with the subversion one. For instance, subversion ignores missing files when committing. And when there are only missing files, svn commit will be a successful no-op with no output. Still, we should stick to our definition including missing files in changes as doing otherwise could cause surprising behaviour for the user.
2012-04-26 13:55:07 +04:00
missing svn file, commit should fail
$ rm s/alpha
$ hg commit --subrepos -m 'abort on missing file'
committing subrepository s
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
2012-12-14 02:37:53 +04:00
abort: cannot commit missing svn entries (in subrepo s)
subrepo/svn: abort on commit with missing file (issue3029) Previous code was printing a traceback because it expected some error output from svn. But sometimes our definition of "changed" differs with the subversion one. For instance, subversion ignores missing files when committing. And when there are only missing files, svn commit will be a successful no-op with no output. Still, we should stick to our definition including missing files in changes as doing otherwise could cause surprising behaviour for the user.
2012-04-26 13:55:07 +04:00
[255]
$ svn revert s/alpha > /dev/null
subrepo: compare svn subrepo state to last committed revision A subversion project revisions are a subset of the repository revisions, you can ask subversion to update a working directory from one revision to another without changing anything. Unfortunately, Mercurial will think the subrepository has changed and will commit it again. To avoid useless commits, we compare the subrepository state to its actual "parent" revision. To ensure ascending compatibility with existing subrepositories which might reference fake revisions, we also keep comparing with the subrepo working directory revision. NOTE: not sure if this should go in stable or not.
2011-01-22 18:15:40 +03:00
add an unrelated revision in svn and update the subrepo to without
bringing any changes.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn mkdir "$SVNREPOURL/unrelated" -m 'create unrelated'
subrepo: compare svn subrepo state to last committed revision A subversion project revisions are a subset of the repository revisions, you can ask subversion to update a working directory from one revision to another without changing anything. Unfortunately, Mercurial will think the subrepository has changed and will commit it again. To avoid useless commits, we compare the subrepository state to its actual "parent" revision. To ensure ascending compatibility with existing subrepositories which might reference fake revisions, we also keep comparing with the subrepo working directory revision. NOTE: not sure if this should go in stable or not.
2011-01-22 18:15:40 +03:00
Committed revision 4.
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn up -q s
subrepo: compare svn subrepo state to last committed revision A subversion project revisions are a subset of the repository revisions, you can ask subversion to update a working directory from one revision to another without changing anything. Unfortunately, Mercurial will think the subrepository has changed and will commit it again. To avoid useless commits, we compare the subrepository state to its actual "parent" revision. To ensure ascending compatibility with existing subrepositories which might reference fake revisions, we also keep comparing with the subrepo working directory revision. NOTE: not sure if this should go in stable or not.
2011-01-22 18:15:40 +03:00
$ hg sum
parent: 2:* tip (glob)
Message!
branch: default
commit: (clean)
update: (current)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ echo a > s/a
should be empty despite change to s/a
$ hg st
add a commit from svn
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ cd "$WCROOT/src"
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn up -q
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ echo xyz >> alpha
$ svn propset svn:mime-type 'text/xml' alpha
property 'svn:mime-type' set on 'alpha'
$ svn ci -m 'amend a from svn'
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Sending *alpha (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
Transmitting file data .
subrepo: compare svn subrepo state to last committed revision A subversion project revisions are a subset of the repository revisions, you can ask subversion to update a working directory from one revision to another without changing anything. Unfortunately, Mercurial will think the subrepository has changed and will commit it again. To avoid useless commits, we compare the subrepository state to its actual "parent" revision. To ensure ascending compatibility with existing subrepositories which might reference fake revisions, we also keep comparing with the subrepo working directory revision. NOTE: not sure if this should go in stable or not.
2011-01-22 18:15:40 +03:00
Committed revision 5.
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ cd ../../sub/t
this commit from hg will fail
$ echo zzz >> s/alpha
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ (hg ci --subrepos -m 'amend alpha from hg' 2>&1; echo "[$?]") | grep -vi 'out of date'
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
committing subrepository s
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
abort: svn:*Commit failed (details follow): (glob)
tests: drop a bunch of sed calls from unified tests
2010-09-22 01:44:13 +04:00
[255]
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ svn revert -q s/alpha
this commit fails because of meta changes
$ svn propset svn:mime-type 'text/html' s/alpha
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
property 'svn:mime-type' set on 's/alpha' (glob)
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ (hg ci --subrepos -m 'amend alpha from hg' 2>&1; echo "[$?]") | grep -vi 'out of date'
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
committing subrepository s
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
abort: svn:*Commit failed (details follow): (glob)
tests: drop a bunch of sed calls from unified tests
2010-09-22 01:44:13 +04:00
[255]
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ svn revert -q s/alpha
this commit fails because of externals changes
$ echo zzz > s/externals/other
subrepos: abort commit by default if a subrepo is dirty (BC) This changeset flips the default value of ui.commitsubrepos setting from True to False and adds a --subrepos flag to commit. The commit, status, and diff commands behave like this with regard to recusion and the ui.commitsubrepos setting: | recurses | recurses | by default | with --subrepos --------+---------------+---------------- commit: | commitsubrepo | True status: | False | True diff: | False | True By changing the default from True to False, the table becomes consistent in the two columns: * without --subrepos on the command line, commit will abort if a subrepo is dirty and status/diff wont show changes inside subrepos. * with --subrepos, all three commands will recurse. A --subrepos flag on the command line overrides the config settin.g
2011-10-21 02:33:08 +04:00
$ hg ci --subrepos -m 'amend externals from hg'
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
committing subrepository s
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
2012-12-14 02:37:53 +04:00
abort: cannot commit svn externals (in subrepo s)
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
subrepos: handle diff nodeids in subrepos, not before Subversion nodeids are integer revisions.
2010-09-11 00:52:00 +04:00
$ hg diff --subrepos -r 1:2 | grep -v diff
--- a/.hgsubstate Thu Jan 01 00:00:00 1970 +0000
+++ b/.hgsubstate Thu Jan 01 00:00:00 1970 +0000
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
@@ -1,2 +1,2 @@
subrepos: handle diff nodeids in subrepos, not before Subversion nodeids are integer revisions.
2010-09-11 00:52:00 +04:00
-2 s
+3 s
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
2 subdir/s
subrepos: handle diff nodeids in subrepos, not before Subversion nodeids are integer revisions.
2010-09-11 00:52:00 +04:00
--- a/a Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +1,2 @@
a
+a
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ svn revert -q s/externals/other
this commit fails because of externals meta changes
$ svn propset svn:mime-type 'text/html' s/externals/other
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
property 'svn:mime-type' set on 's/externals/other' (glob)
subrepos: abort commit by default if a subrepo is dirty (BC) This changeset flips the default value of ui.commitsubrepos setting from True to False and adds a --subrepos flag to commit. The commit, status, and diff commands behave like this with regard to recusion and the ui.commitsubrepos setting: | recurses | recurses | by default | with --subrepos --------+---------------+---------------- commit: | commitsubrepo | True status: | False | True diff: | False | True By changing the default from True to False, the table becomes consistent in the two columns: * without --subrepos on the command line, commit will abort if a subrepo is dirty and status/diff wont show changes inside subrepos. * with --subrepos, all three commands will recurse. A --subrepos flag on the command line overrides the config settin.g
2011-10-21 02:33:08 +04:00
$ hg ci --subrepos -m 'amend externals from hg'
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
committing subrepository s
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
2012-12-14 02:37:53 +04:00
abort: cannot commit svn externals (in subrepo s)
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ svn revert -q s/externals/other
clone
$ cd ..
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ hg clone t tc
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
updating to branch default
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
A tc/s/alpha (glob)
U tc/s (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into 'tc/s/externals'* (glob)
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
A tc/s/externals/other (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
Checked out external at revision 1.
Checked out revision 3.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
A tc/subdir/s/alpha (glob)
U tc/subdir/s (glob)
subrepo: fix up svn test output
2011-04-07 18:47:30 +04:00
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into 'tc/subdir/s/externals'* (glob)
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
A tc/subdir/s/externals/other (glob)
subrepo: fix up svn test output
2011-04-07 18:47:30 +04:00
Checked out external at revision 1.
Checked out revision 2.
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd tc
debugsub in clone
tests: drop a bunch of sed calls from unified tests
2010-09-22 01:44:13 +04:00
$ hg debugsub
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
path s
test-subrepo-svn.t: ignore that subversion %-encodes $TESTTMP Use a glob instead of expecting $TESTTMP.
2010-10-10 00:06:22 +04:00
source file://*/svn-repo/src (glob)
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
revision 3
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
path subdir/s
source file://*/svn-repo/src (glob)
revision 2
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
verify subrepo is contained within the repo directory
tests: use $PYTHON instead of hardcoding python This makes running the testsuite with pypy possible.
2014-10-15 23:35:59 +04:00
$ $PYTHON -c "import os.path; print os.path.exists('s')"
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
True
subrepo: test & fix svn subrepo removal
2010-11-05 17:13:22 +03:00
update to nullrev (must delete the subrepo)
$ hg up null
0 files updated, 0 files merged, 3 files removed, 0 files unresolved
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
$ ls
subrepo: make update -C clean the working directory for svn subrepos This makes 'hg update --clean' behave the same way for both kinds of subrepositories. Before Subversion subrepos did not take the clean parameter into account, but just updated to the given revision and merged uncommitted changes into that.
2011-01-31 15:33:41 +03:00
Check hg update --clean
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ cd "$TESTTMP/sub/t"
subrepo: make update -C clean the working directory for svn subrepos This makes 'hg update --clean' behave the same way for both kinds of subrepositories. Before Subversion subrepos did not take the clean parameter into account, but just updated to the given revision and merged uncommitted changes into that.
2011-01-31 15:33:41 +03:00
$ cd s
$ echo c0 > alpha
$ echo c1 > f1
$ echo c1 > f2
$ svn add f1 -q
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn status | sort
tests: fixes for svn 1.4.2
2011-02-16 01:19:11 +03:00
? * a (glob)
? * f2 (glob)
A * f1 (glob)
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
M * alpha (glob)
Performing status on external item at 'externals'* (glob)
X * externals (glob)
subrepo: fix update -C with svn subrepos when cwd != repo.root
2011-02-01 23:39:28 +03:00
$ cd ../..
$ hg -R t update -C
subrepo: make update -C clean the working directory for svn subrepos This makes 'hg update --clean' behave the same way for both kinds of subrepositories. Before Subversion subrepos did not take the clean parameter into account, but just updated to the given revision and merged uncommitted changes into that.
2011-01-31 15:33:41 +03:00
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into 't/s/externals'* (glob)
subrepo: make update -C clean the working directory for svn subrepos This makes 'hg update --clean' behave the same way for both kinds of subrepositories. Before Subversion subrepos did not take the clean parameter into account, but just updated to the given revision and merged uncommitted changes into that.
2011-01-31 15:33:41 +03:00
Checked out external at revision 1.
Checked out revision 3.
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
subrepo: fix update -C with svn subrepos when cwd != repo.root
2011-02-01 23:39:28 +03:00
$ cd t/s
test-subrepo-svn: fix non-determinism The test was randomly failing with: --- /tests/test-subrepo-svn.t +++ /test-subrepo-svn.t.err @@ -273,10 +273,10 @@ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd t/s $ svn status - ? * a (glob) - X * externals (glob) - ? * f1 (glob) - ? * f2 (glob) + ? f1 + ? f2 + ? a + X externals Performing status on external item at 'externals'* (glob)
2012-04-27 12:17:55 +04:00
$ svn status | sort
tests: fixes for svn 1.4.2
2011-02-16 01:19:11 +03:00
? * a (glob)
? * f1 (glob)
? * f2 (glob)
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Performing status on external item at 'externals'* (glob)
test-subrepo-svn: fix non-determinism The test was randomly failing with: --- /tests/test-subrepo-svn.t +++ /test-subrepo-svn.t.err @@ -273,10 +273,10 @@ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd t/s $ svn status - ? * a (glob) - X * externals (glob) - ? * f1 (glob) - ? * f2 (glob) + ? f1 + ? f2 + ? a + X externals Performing status on external item at 'externals'* (glob)
2012-04-27 12:17:55 +04:00
X * externals (glob)
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
Sticky subrepositories, no changes
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ cd "$TESTTMP/sub/t"
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ hg id -n
2
$ cd s
$ svnversion
3
$ cd ..
$ hg update 1
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
U *s/alpha (glob)
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into '*s/externals'* (glob)
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
Checked out external at revision 1.
Checked out revision 2.
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -n
1
$ cd s
$ svnversion
2
$ cd ..
spelling: fixes from spell checker
2014-04-13 21:01:00 +04:00
Sticky subrepositories, file changes
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ touch s/f1
$ cd s
$ svn add f1
A f1
$ cd ..
$ hg id -n
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
1+
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ cd s
$ svnversion
2M
$ cd ..
$ hg update tip
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: 2, remote revision: 3)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for s differ
subrepo: remove superfluous newline from subrepo prompt
2014-10-01 03:08:17 +04:00
use (l)ocal source (2) or (r)emote source (3)? l
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -n
2+
$ cd s
$ svnversion
2M
$ cd ..
$ hg update --clean tip
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
U *s/alpha (glob)
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into '*s/externals'* (glob)
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
Checked out external at revision 1.
Checked out revision 3.
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Sticky subrepository, revision updates
$ hg id -n
2
$ cd s
$ svnversion
3
$ cd ..
$ cd s
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn update -qr 1
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ cd ..
$ hg update 1
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: 3, remote revision: 2)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for s differ (in checked out version)
subrepo: remove superfluous newline from subrepo prompt
2014-10-01 03:08:17 +04:00
use (l)ocal source (1) or (r)emote source (2)? l
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -n
1+
$ cd s
$ svnversion
1
$ cd ..
Sticky subrepository, file changes and revision updates
$ touch s/f1
$ cd s
$ svn add f1
A f1
$ svnversion
1M
$ cd ..
$ hg id -n
1+
$ hg update tip
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: 3, remote revision: 3)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
subrepository sources for s differ
subrepo: remove superfluous newline from subrepo prompt
2014-10-01 03:08:17 +04:00
use (l)ocal source (1) or (r)emote source (3)? l
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -n
identity: show trailing '+' for dirty subrepos (issue2839)
2012-07-27 15:56:19 +04:00
2+
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ cd s
$ svnversion
1M
$ cd ..
Sticky repository, update --clean
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
$ hg update --clean tip | grep -v 's[/\]externals[/\]other'
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
U *s/alpha (glob)
U *s (glob)
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into '*s/externals'* (glob)
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
Checked out external at revision 1.
Checked out revision 3.
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -n
2
$ cd s
$ svnversion
3
$ cd ..
Test subrepo already at intended revision:
$ cd s
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn update -qr 2
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
$ cd ..
$ hg update 1
merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options). # HG changeset patch # User Angel Ezquerra <angel.ezquerra@gmail.com> # Date 1378420708 -7200 # Fri Sep 06 00:38:28 2013 +0200 # Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d # Parent 796d34e1b749b79834321ef1181ed8433a5515d9 merge: let the user choose to merge, keep local or keep remote subrepo revisions When a subrepo has changed on the local and remote revisions, prompt the user whether it wants to merge those subrepo revisions, keep the local revision or keep the remote revision. Up until now mercurial would always perform a merge on a subrepo that had changed on the local and the remote revisions. This is often inconvenient. For example: - You may want to perform the actual subrepo merge after you have merged the parent subrepo files. - Some subrepos may be considered "read only", in the sense that you are not supposed to add new revisions to them. In those cases "merging a subrepo" means choosing which _existing_ revision you want to use on the merged revision. This is often the case for subrepos that contain binary dependencies (such as DLLs, etc). This new prompt makes mercurial better cope with those common scenarios. Notes: - The default behavior (which is the one that is used when ui is not interactive) remains unchanged (i.e. merge is the default action). - This prompt will be shown even if the ui --tool flag is set. - I don't know of a way to test the "keep local" and "keep remote" options (i.e. to force the test to choose those options).
2013-09-06 02:38:28 +04:00
subrepository s diverged (local revision: 3, remote revision: 2)
(M)erge, keep (l)ocal or keep (r)emote? m
subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
2011-02-09 12:53:09 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -n
1+
$ cd s
$ svnversion
2
$ cd ..
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
Test case where subversion would fail to update the subrepo because there
are unknown directories being replaced by tracked ones (happens with rebase).
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ cd "$WCROOT/src"
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
$ mkdir dir
$ echo epsilon.py > dir/epsilon.py
$ svn add dir
A dir
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
A dir/epsilon.py (glob)
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
$ svn ci -m 'Add dir/epsilon.py'
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Adding *dir (glob)
Adding *dir/epsilon.py (glob)
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
Transmitting file data .
Committed revision 6.
$ cd ../..
$ hg init rebaserepo
$ cd rebaserepo
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn co -r5 --quiet "$SVNREPOURL"/src s
$ echo "s = [svn] $SVNREPOURL/src" >> .hgsub
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
$ hg add .hgsub
$ hg ci -m addsub
$ echo a > a
$ hg ci -Am adda
adding a
$ hg up 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn up -qr6 s
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
$ hg ci -m updatesub
created new head
$ echo pyc > s/dir/epsilon.pyc
$ hg up 1
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
D *s/dir (glob)
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
Fetching external item into '*s/externals'* (glob)
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
2011-03-04 16:00:49 +03:00
Checked out external at revision 1.
Checked out revision 5.
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
tests: change odd uses of 'if hghave' to #if
2012-06-10 15:01:40 +04:00
$ hg up -q 2
svn subrepos: work around checkout obstructions (issue2752) We do this by ensuring the working copy is clean and then blowing away the working copy and replacing it with one from the desired path. We could probably use 'svn switch' to do this more efficiently, but there's some subtle logic required to get that right and this is more likely to work reliably.
2011-06-18 00:22:50 +04:00
Modify one of the externals to point to a different path so we can
test having obstructions when switching branches on checkout:
$ hg checkout tip
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ echo "obstruct = [svn] $SVNREPOURL/externals" >> .hgsub
$ svn co -r5 --quiet "$SVNREPOURL"/externals obstruct
check-code: fix issues with finding patterns in unified tests, fix tests - old-style patterns without ^ were getting improperly anchored - finditer was matching against beginning of line poorly - \s was matching newlines - [^x] was matching newlines so we: - remove earlier hacks for multiline matching - fix unified test anchoring by adding .* - replace \s with [ \t] - replace [^x] with [^\nx] - force all matches into multiline mode so ^ anchors work This uncovers a number of test issues that are then repaired.
2011-10-28 02:22:04 +04:00
$ hg commit -m 'Start making obstructed working copy'
svn subrepos: work around checkout obstructions (issue2752) We do this by ensuring the working copy is clean and then blowing away the working copy and replacing it with one from the desired path. We could probably use 'svn switch' to do this more efficiently, but there's some subtle logic required to get that right and this is more likely to work reliably.
2011-06-18 00:22:50 +04:00
$ hg book other
$ hg co -r 'p1(tip)'
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
update: when deactivating a bookmark, print a message This helps prevent user confusion when innocent-seeming commands like 'hg update -C .' are run.
2014-05-14 23:49:55 +04:00
(leaving bookmark other)
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ echo "obstruct = [svn] $SVNREPOURL/src" >> .hgsub
$ svn co -r5 --quiet "$SVNREPOURL"/src obstruct
svn subrepos: work around checkout obstructions (issue2752) We do this by ensuring the working copy is clean and then blowing away the working copy and replacing it with one from the desired path. We could probably use 'svn switch' to do this more efficiently, but there's some subtle logic required to get that right and this is more likely to work reliably.
2011-06-18 00:22:50 +04:00
$ hg commit -m 'Other branch which will be obstructed'
created new head
Switching back to the head where we have another path mapped to the
same subrepo should work if the subrepo is clean.
$ hg co other
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
A *obstruct/other (glob)
svn subrepos: work around checkout obstructions (issue2752) We do this by ensuring the working copy is clean and then blowing away the working copy and replacing it with one from the desired path. We could probably use 'svn switch' to do this more efficiently, but there's some subtle logic required to get that right and this is more likely to work reliably.
2011-06-18 00:22:50 +04:00
Checked out revision 1.
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
update: show message when a bookmark is activated by update When updating to a bookmark, mention that the bookmark is now active. This is a reminder that update does not move the current bookmark if an explicit target is given - instead it activates that target.
2013-03-07 07:17:56 +04:00
(activating bookmark other)
svn subrepos: work around checkout obstructions (issue2752) We do this by ensuring the working copy is clean and then blowing away the working copy and replacing it with one from the desired path. We could probably use 'svn switch' to do this more efficiently, but there's some subtle logic required to get that right and this is more likely to work reliably.
2011-06-18 00:22:50 +04:00
This is surprising, but is also correct based on the current code:
$ echo "updating should (maybe) fail" > obstruct/other
$ hg co tip
update: add error message for dirty non-linear update with no rev Previously, the error message for a dirty non-linear update was the same (and relatively unhelpful) whether or not a rev was specified. This patch and an upcoming one will introduce separate, more helpful hints.
2013-09-24 07:07:30 +04:00
abort: uncommitted changes
(commit or update --clean to discard changes)
svn subrepos: work around checkout obstructions (issue2752) We do this by ensuring the working copy is clean and then blowing away the working copy and replacing it with one from the desired path. We could probably use 'svn switch' to do this more efficiently, but there's some subtle logic required to get that right and this is more likely to work reliably.
2011-06-18 00:22:50 +04:00
[255]
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Point to a Subversion branch which has since been deleted and recreated
First, create that condition in the repository.
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ hg ci --subrepos -m cleanup | grep -v Updating
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
committing subrepository obstruct
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
Sending obstruct/other (glob)
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Transmitting file data .
Committed revision 7.
At revision 7.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn mkdir -m "baseline" $SVNREPOURL/trunk
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Committed revision 8.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn copy -m "initial branch" $SVNREPOURL/trunk $SVNREPOURL/branch
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Committed revision 9.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn co --quiet "$SVNREPOURL"/branch tempwc
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
$ cd tempwc
$ echo "something old" > somethingold
$ svn add somethingold
A somethingold
$ svn ci -m 'Something old'
Adding somethingold
Transmitting file data .
Committed revision 10.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn rm -m "remove branch" $SVNREPOURL/branch
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Committed revision 11.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn copy -m "recreate branch" $SVNREPOURL/trunk $SVNREPOURL/branch
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Committed revision 12.
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn up -q
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
$ echo "something new" > somethingnew
$ svn add somethingnew
A somethingnew
$ svn ci -m 'Something new'
Adding somethingnew
Transmitting file data .
Committed revision 13.
$ cd ..
$ rm -rf tempwc
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn co "$SVNREPOURL/branch"@10 recreated
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
A recreated/somethingold (glob)
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Checked out revision 10.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ echo "recreated = [svn] $SVNREPOURL/branch" >> .hgsub
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
$ hg ci -m addsub
$ cd recreated
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
$ svn up -q
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
$ cd ..
$ hg ci -m updatesub
$ hg up -r-2
test-svn-subrepo: fix reference output for svn 1.7 I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
2011-12-02 19:50:48 +04:00
D *recreated/somethingnew (glob)
A *recreated/somethingold (glob)
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
Checked out revision 10.
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
update: when deactivating a bookmark, print a message This helps prevent user confusion when innocent-seeming commands like 'hg update -C .' are run.
2014-05-14 23:49:55 +04:00
(leaving bookmark other)
tests: don't use 'test -e' On Solaris 10: $ test -e f test: argument expected
2011-10-17 02:11:56 +04:00
$ test -f recreated/somethingold
subrepo: correct revision in svn checkout A Subversion subrepo checkout uses a url and --revision which does not do the correct thing when specifying a revision of a branch that has since been deleted and recreated. The checkout needs to specify the revision as URL@REV instead.
2011-06-30 22:22:12 +04:00
archive: make it work with svn subrepos (issue3308) - _svncommand() in files() returns a tuple since 1ca3bbcf0c2a not a string. - _svncommand() in filedata() returns a tuple not a string. - "svn list" returns files but also directories. - "svn list" is not recursive by default. I have no idea what happens to svn:externals possibly embedded in the svn subrepository.
2012-04-16 13:48:15 +04:00
Test archive
$ hg archive -S ../archive-all --debug
archiving: 0/2 files (0.00%)
archiving: .hgsub 1/2 files (50.00%)
archiving: .hgsubstate 2/2 files (100.00%)
archiving (obstruct): 0/1 files (0.00%)
archiving (obstruct): 1/1 files (100.00%)
subrepos: process subrepos in sorted order Add sorted() in places found by testing with PYTHONHASHSEED=random and code inspection. An alternative to sprinkling sorted() all over would be to change substate to a custom dict with sorted iterators...
2012-12-12 05:38:14 +04:00
archiving (recreated): 0/1 files (0.00%)
archiving (recreated): 1/1 files (100.00%)
archive: make it work with svn subrepos (issue3308) - _svncommand() in files() returns a tuple since 1ca3bbcf0c2a not a string. - _svncommand() in filedata() returns a tuple not a string. - "svn list" returns files but also directories. - "svn list" is not recursive by default. I have no idea what happens to svn:externals possibly embedded in the svn subrepository.
2012-04-16 13:48:15 +04:00
archiving (s): 0/2 files (0.00%)
archiving (s): 1/2 files (50.00%)
archiving (s): 2/2 files (100.00%)
subrepo: fix default implementation of forget() (issue3404)
2012-04-27 13:02:16 +04:00
subrepo: propagate matcher to subrepos when archiving Add a match object to subrepo.archive(). This will allow the -X and -I options to be honored inside subrepos when archiving. They formerly only affect the top level repo.
2012-06-17 06:34:06 +04:00
$ hg archive -S ../archive-exclude --debug -X **old
archiving: 0/2 files (0.00%)
archiving: .hgsub 1/2 files (50.00%)
archiving: .hgsubstate 2/2 files (100.00%)
archiving (obstruct): 0/1 files (0.00%)
archiving (obstruct): 1/1 files (100.00%)
subrepos: process subrepos in sorted order Add sorted() in places found by testing with PYTHONHASHSEED=random and code inspection. An alternative to sprinkling sorted() all over would be to change substate to a custom dict with sorted iterators...
2012-12-12 05:38:14 +04:00
archiving (recreated): 0 files
subrepo: propagate matcher to subrepos when archiving Add a match object to subrepo.archive(). This will allow the -X and -I options to be honored inside subrepos when archiving. They formerly only affect the top level repo.
2012-06-17 06:34:06 +04:00
archiving (s): 0/2 files (0.00%)
archiving (s): 1/2 files (50.00%)
archiving (s): 2/2 files (100.00%)
$ find ../archive-exclude | sort
../archive-exclude
../archive-exclude/.hg_archival.txt
../archive-exclude/.hgsub
../archive-exclude/.hgsubstate
../archive-exclude/obstruct
../archive-exclude/obstruct/other
../archive-exclude/s
../archive-exclude/s/alpha
../archive-exclude/s/dir
../archive-exclude/s/dir/epsilon.py
subrepo: fix default implementation of forget() (issue3404)
2012-04-27 13:02:16 +04:00
Test forgetting files, not implemented in svn subrepo, used to
traceback
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
#if no-windows
subrepo: fix default implementation of forget() (issue3404)
2012-04-27 13:02:16 +04:00
$ hg forget 'notafile*'
notafile*: No such file or directory
[1]
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
#else
$ hg forget 'notafile'
notafile: * (glob)
[1]
#endif
subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.
2012-04-30 19:03:15 +04:00
Test a subrepo referencing a just moved svn path. Last commit rev will
be different from the revision, and the path will be different as
well.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ cd "$WCROOT"
subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.
2012-04-30 19:03:15 +04:00
$ svn up > /dev/null
$ mkdir trunk/subdir branches
$ echo a > trunk/subdir/a
$ svn add trunk/subdir branches
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
A trunk/subdir (glob)
A trunk/subdir/a (glob)
subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.
2012-04-30 19:03:15 +04:00
A branches
$ svn ci -m addsubdir
Adding branches
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
Adding trunk/subdir (glob)
Adding trunk/subdir/a (glob)
subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.
2012-04-30 19:03:15 +04:00
Transmitting file data .
Committed revision 14.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn cp -m branchtrunk $SVNREPOURL/trunk $SVNREPOURL/branches/somebranch
subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.
2012-04-30 19:03:15 +04:00
Committed revision 15.
$ cd ..
$ hg init repo2
$ cd repo2
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ svn co $SVNREPOURL/branches/somebranch/subdir
test-subrepo-svn.t: partially adapt for Windows hg forget 'notafile*' is changed to use a name that is valid on Windows so we still get the same error ... but the error message is disabled because it varies with the Windows version.
2012-06-23 20:54:08 +04:00
A subdir/a (glob)
subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.
2012-04-30 19:03:15 +04:00
Checked out revision 15.
tests: cleanup of svn url handling The subversion tests used different tricks to create properly encoded URLs, partly due to partial support for different ways of running the tests on windows. Now we only need/support one way of running the tests on windows. Windows URLs should look like 'file:///c:/foo%20bar' and on Unix platforms like 'file:///tmp/baz'. 'pwd' in the test framework will on Windows emit paths like 'c:/foo bar'. Explicit handling of backslashes in paths is thus no longer needed and is removed. Paths on windows do however need an extra '/' compared to other platforms. This change makes test-subrepo-svn.t pass on windows with msys. Other tests might need more work.
2012-06-26 05:35:22 +04:00
$ echo "subdir = [svn] $SVNREPOURL/branches/somebranch/subdir" > .hgsub
subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.
2012-04-30 19:03:15 +04:00
$ hg add .hgsub
$ hg ci -m addsub
$ hg up null
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ hg up
A *subdir/a (glob)
Checked out revision 15.
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ..
subrepo: make "_sanitize()" work "_sanitize()" was introduced by 5131f2755f60 on "stable" branch, but it has done nothing for sanitizing since 5131f2755f60. "_sanitize()" assumes "Visitor" design pattern: "os.walk()" should invoke specified function ("v" in this case) for each directory elements under specified path but "os.walk()" assumes "Iterator" design pattern: callers of it should drive loop to scan each directory elements under specified path by themselves with the returned generator object Because of this mismatching, "_sanitize()" just discards the generator object returned by "os.walk()" and does nothing for sanitizing. This patch makes "_sanitize()" work. This patch also changes the format of warning message to show each unlinked files, for multiple appearances of "potentially hostile .hg/hgrc".
2014-05-08 14:03:00 +04:00
Test sanitizing ".hg/hgrc" in subrepo
$ cd sub/t
$ hg update -q -C tip
$ cd s
$ mkdir .hg
$ echo '.hg/hgrc in svn repo' > .hg/hgrc
$ mkdir -p sub/.hg
$ echo 'sub/.hg/hgrc in svn repo' > sub/.hg/hgrc
$ svn add .hg sub
A .hg
A .hg/hgrc (glob)
A sub
A sub/.hg (glob)
A sub/.hg/hgrc (glob)
$ svn ci -m 'add .hg/hgrc to be sanitized at hg update'
Adding .hg
Adding .hg/hgrc (glob)
Adding sub
Adding sub/.hg (glob)
Adding sub/.hg/hgrc (glob)
Transmitting file data ..
Committed revision 16.
$ svn up -q
$ cd ..
$ hg commit -S -m 'commit with svn revision including .hg/hgrc'
$ grep ' s$' .hgsubstate
16 s
$ cd ..
subrepo: make "_sanitize()" take absolute path to the root of subrepo Before this patch, "hg update" doesn't sanitize ".hg/hgrc" in non-hg subrepos correctly, if "hg update" is executed not at the root of the parent repository. "_sanitize()" takes relative path to subrepo from the root of the parent repository, and passes it to "os.walk()". In this case, "os.walk()" expects CWD to be equal to the root of the parent repository. So, "os.walk()" can't find specified path (or may scan unexpected path), if CWD isn't equal to the root of the parent repository. Non-hg subrepo under nested hg-subrepos may cause same problem, too: CWD may be equal to the root of the outer most repository, or so. This patch makes "_sanitize()" take absolute path to the root of subrepo to sanitize correctly in such cases. This patch doesn't normalize the path to hostile files as the one relative to CWD (or the root of the outer most repository), to fix the problem in the simple way suitable for "stable". Normalizing should be done in the future: maybe as a part of the migration to vfs.
2014-05-08 14:03:00 +04:00
$ hg -R tc pull -u -q 2>&1 | sort
warning: removing potentially hostile 'hgrc' in '$TESTTMP/sub/tc/s/.hg' (glob)
warning: removing potentially hostile 'hgrc' in '$TESTTMP/sub/tc/s/sub/.hg' (glob)
subrepo: make "_sanitize()" work "_sanitize()" was introduced by 5131f2755f60 on "stable" branch, but it has done nothing for sanitizing since 5131f2755f60. "_sanitize()" assumes "Visitor" design pattern: "os.walk()" should invoke specified function ("v" in this case) for each directory elements under specified path but "os.walk()" assumes "Iterator" design pattern: callers of it should drive loop to scan each directory elements under specified path by themselves with the returned generator object Because of this mismatching, "_sanitize()" just discards the generator object returned by "os.walk()" and does nothing for sanitizing. This patch makes "_sanitize()" work. This patch also changes the format of warning message to show each unlinked files, for multiple appearances of "potentially hostile .hg/hgrc".
2014-05-08 14:03:00 +04:00
$ cd tc
$ grep ' s$' .hgsubstate
16 s
tests: cat error messages are different on Solaris
2014-07-21 22:27:24 +04:00
$ test -f s/.hg/hgrc
subrepo: make "_sanitize()" work "_sanitize()" was introduced by 5131f2755f60 on "stable" branch, but it has done nothing for sanitizing since 5131f2755f60. "_sanitize()" assumes "Visitor" design pattern: "os.walk()" should invoke specified function ("v" in this case) for each directory elements under specified path but "os.walk()" assumes "Iterator" design pattern: callers of it should drive loop to scan each directory elements under specified path by themselves with the returned generator object Because of this mismatching, "_sanitize()" just discards the generator object returned by "os.walk()" and does nothing for sanitizing. This patch makes "_sanitize()" work. This patch also changes the format of warning message to show each unlinked files, for multiple appearances of "potentially hostile .hg/hgrc".
2014-05-08 14:03:00 +04:00
[1]
tests: cat error messages are different on Solaris
2014-07-21 22:27:24 +04:00
$ test -f s/sub/.hg/hgrc
subrepo: make "_sanitize()" work "_sanitize()" was introduced by 5131f2755f60 on "stable" branch, but it has done nothing for sanitizing since 5131f2755f60. "_sanitize()" assumes "Visitor" design pattern: "os.walk()" should invoke specified function ("v" in this case) for each directory elements under specified path but "os.walk()" assumes "Iterator" design pattern: callers of it should drive loop to scan each directory elements under specified path by themselves with the returned generator object Because of this mismatching, "_sanitize()" just discards the generator object returned by "os.walk()" and does nothing for sanitizing. This patch makes "_sanitize()" work. This patch also changes the format of warning message to show each unlinked files, for multiple appearances of "potentially hostile .hg/hgrc".
2014-05-08 14:03:00 +04:00
[1]
subrepo: avoid sanitizing ".hg/hgrc" in meta data area for non-hg subrepos Before this patch, sanitizing ".hg/hgrc" scans directories and files also in meta data area for non-hg subrepos: under ".svn" for Subversion subrepo, for example. This may cause not only performance impact (especially in large scale subrepos) but also unexpected removing meta data files. This patch avoids sanitizing ".hg/hgrc" in meta data area for non-hg subrepos. This patch stops checking "ignore" target at the first (case-insensitive) appearance of it, because continuation of scanning is meaningless in almost all cases.
2014-05-08 14:03:00 +04:00
Test that sanitizing is omitted in meta data area:
$ mkdir s/.svn/.hg
$ echo '.hg/hgrc in svn metadata area' > s/.svn/.hg/hgrc
$ hg update -q -C '.^1'
subrepo: make "_sanitize()" work "_sanitize()" was introduced by 5131f2755f60 on "stable" branch, but it has done nothing for sanitizing since 5131f2755f60. "_sanitize()" assumes "Visitor" design pattern: "os.walk()" should invoke specified function ("v" in this case) for each directory elements under specified path but "os.walk()" assumes "Iterator" design pattern: callers of it should drive loop to scan each directory elements under specified path by themselves with the returned generator object Because of this mismatching, "_sanitize()" just discards the generator object returned by "os.walk()" and does nothing for sanitizing. This patch makes "_sanitize()" work. This patch also changes the format of warning message to show each unlinked files, for multiple appearances of "potentially hostile .hg/hgrc".
2014-05-08 14:03:00 +04:00
$ cd ../..
Reference in New Issue Copy Permalink