facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-09 08:18:15 +03:00
Code Issues Projects Releases Wiki Activity
6f3e39c8ee
sapling/tests/test-subrepo-svn.t

688 lines
18 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
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ filter_svn_output () {
tests: make tests for convert with svn portable svn 1.6.x (at least, 1.6.12 or 1.6.17) might display empty lines, even though svn 1.9.x (at least, 1.9.3) doesn't. To make tests for convert with svn portable, this patch adds "|(^$)" regexp to egrep in filter_svn_output. To avoid similar future issue, this patch adds "|(^$)" regexp to all filter_svn_output (and adjusts test-subrepo-svn.t), even though only test-convert-svn-source.t fails with svn 1.6.x, AFAIK.
2016-03-14 18:14:53 +03:00
> egrep -v 'Committing|Transmitting|Updating|(^$)' || true
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
> }
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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A src/alpha
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ mkdir externals
$ echo other > externals/other
$ svn add externals
A externals
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A externals/other
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm 'Add 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
$ 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'
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm 'Setting externals'
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ 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
subrepo: disable git and svn subrepos by default (BC) (SEC) We have a security issue with git subrepos. I'm not sure if svn subrepo is vulnerable, but it seems not 100% safe to allow writing arbitrary data into a metadata directory. So for now, only hg subrepo is enabled by default. Maybe we should improve the help to describe why git/svn subrepos are disabled.
2017-11-05 15:51:42 +03:00
svn subrepo is disabled by default
$ hg ci -m1
subrepo: use per-type config options to enable subrepos We change subrepos.allowed from a list of allowed subrepo types to a combination of a master switch and per-type boolean flag. If the master switch is set, subrepos can be disabled wholesale. If subrepos are globally enabled, then per-type options are consulted. Mercurial repos are enabled by default. Everything else is disabled by default.
2017-11-07 09:32:41 +03:00
abort: svn subrepos not allowed
subrepo: disable git and svn subrepos by default (BC) (SEC) We have a security issue with git subrepos. I'm not sure if svn subrepo is vulnerable, but it seems not 100% safe to allow writing arbitrary data into a metadata directory. So for now, only hg subrepo is enabled by default. Maybe we should improve the help to describe why git/svn subrepos are disabled.
2017-11-05 15:51:42 +03:00
(see 'hg help config.subrepos' for details)
[255]
so enable it
$ cat >> $HGRCPATH <<EOF
> [subrepos]
subrepo: use per-type config options to enable subrepos We change subrepos.allowed from a list of allowed subrepo types to a combination of a master switch and per-type boolean flag. If the master switch is set, subrepos can be disabled wholesale. If subrepos are globally enabled, then per-type options are consulted. Mercurial repos are enabled by default. Everything else is disabled by default.
2017-11-07 09:32:41 +03:00
> svn:allowed = true
subrepo: disable git and svn subrepos by default (BC) (SEC) We have a security issue with git subrepos. I'm not sure if svn subrepo is vulnerable, but it seems not 100% safe to allow writing arbitrary data into a metadata directory. So for now, only hg subrepo is enabled by default. Maybe we should improve the help to describe why git/svn subrepos are disabled.
2017-11-05 15:51:42 +03:00
> EOF
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
$ 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)
summary: move the parents phase marker to commit line (issue4688) The phase of the pending commit depends on the parent of the working directory and on the phases.newcommit configuration. First, this information rather depend on the commit line which describe the pending commit. Then, we only want to be advertised when the pending phase is going to be higher than the default new commit phase. So the format will change from $ hg summary parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) update: (current) phases: 1 secret (secret) to parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret) update: (current) phases: 1 secret
2015-05-29 23:23:58 +03:00
phases: 2 draft
subrepo: fix status check on SVN subrepos (issue2445)
2010-10-21 12:28:51 +04:00
$ 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
tests: convert the 'file://\$TESTTMP' rule to an automatic substitution The rule only triggered on non Windows platforms, even though Windows also required an adjustment. Automatic seems better. The aggressive globbing in test-subrepo-svn.t was found and rewritten by the substitution.
2017-12-16 19:32:10 +03:00
source file:/*/$TESTTMP/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
tests: convert the 'file://\$TESTTMP' rule to an automatic substitution The rule only triggered on non Windows platforms, even though Windows also required an adjustment. Automatic seems better. The aggressive globbing in test-subrepo-svn.t was found and rewritten by the substitution.
2017-12-16 19:32:10 +03:00
source file:/*/$TESTTMP/svn-repo/src (glob)
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
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)
summary: move the parents phase marker to commit line (issue4688) The phase of the pending commit depends on the parent of the working directory and on the phases.newcommit configuration. First, this information rather depend on the commit line which describe the pending commit. Then, we only want to be advertised when the pending phase is going to be higher than the default new commit phase. So the format will change from $ hg summary parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) update: (current) phases: 1 secret (secret) to parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret) update: (current) phases: 1 secret
2015-05-29 23:23:58 +03:00
phases: 2 draft
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ hg commit --subrepos -m 'Message!' | filter_svn_output
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
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
tests: convert the 'file://\$TESTTMP' rule to an automatic substitution The rule only triggered on non Windows platforms, even though Windows also required an adjustment. Automatic seems better. The aggressive globbing in test-subrepo-svn.t was found and rewritten by the substitution.
2017-12-16 19:32:10 +03:00
source file:/*/$TESTTMP/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
tests: convert the 'file://\$TESTTMP' rule to an automatic substitution The rule only triggered on non Windows platforms, even though Windows also required an adjustment. Automatic seems better. The aggressive globbing in test-subrepo-svn.t was found and rewritten by the substitution.
2017-12-16 19:32:10 +03:00
source file:/*/$TESTTMP/svn-repo/src (glob)
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
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: make the output references to subrepositories consistent Well, mostly. The annotation on subrepo functions tacks on a parenthetical to the abort message, which seems reasonable for a generic mechanism. But now all messages consistently spell out 'subrepository', and double quote the name of the repo. I noticed the inconsistency in the change for the last commit.
2017-07-09 23:13:30 +03:00
abort: cannot commit missing svn entries (in subrepository "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: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn mkdir "$SVNREPOURL/unrelated" -qm 'create unrelated'
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)
summary: move the parents phase marker to commit line (issue4688) The phase of the pending commit depends on the parent of the working directory and on the phases.newcommit configuration. First, this information rather depend on the commit line which describe the pending commit. Then, we only want to be advertised when the pending phase is going to be higher than the default new commit phase. So the format will change from $ hg summary parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) update: (current) phases: 1 secret (secret) to parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret) update: (current) phases: 1 secret
2015-05-29 23:23:58 +03:00
phases: 3 draft
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
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'
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm 'amend a from svn'
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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
property 'svn:mime-type' set on '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 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: make the output references to subrepositories consistent Well, mostly. The annotation on subrepo functions tacks on a parenthetical to the abort message, which seems reasonable for a generic mechanism. But now all messages consistently spell out 'subrepository', and double quote the name of the repo. I noticed the inconsistency in the change for the last commit.
2017-07-09 23:13:30 +03:00
abort: cannot commit svn externals (in subrepository "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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
property 'svn:mime-type' set on '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: make the output references to subrepositories consistent Well, mostly. The annotation on subrepo functions tacks on a parenthetical to the abort message, which seems reasonable for a generic mechanism. But now all messages consistently spell out 'subrepository', and double quote the name of the repo. I noticed the inconsistency in the change for the last commit.
2017-07-09 23:13:30 +03:00
abort: cannot commit svn externals (in subrepository "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: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A tc/s/alpha
U tc/s
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: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A tc/s/externals/other
tests: unify test-subrepo-svn
2010-08-17 18:53:03 +04:00
Checked out external at revision 1.
Checked out revision 3.
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A tc/subdir/s/alpha
U tc/subdir/s
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: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A tc/subdir/s/externals/other
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
tests: convert the 'file://\$TESTTMP' rule to an automatic substitution The rule only triggered on non Windows platforms, even though Windows also required an adjustment. Automatic seems better. The aggressive globbing in test-subrepo-svn.t was found and rewritten by the substitution.
2017-12-16 19:32:10 +03:00
source file:/*/$TESTTMP/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
tests: convert the 'file://\$TESTTMP' rule to an automatic substitution The rule only triggered on non Windows platforms, even though Windows also required an adjustment. Automatic seems better. The aggressive globbing in test-subrepo-svn.t was found and rewritten by the substitution.
2017-12-16 19:32:10 +03:00
source file:/*/$TESTTMP/svn-repo/src (glob)
subrepo: prune empty directories when removing svn subrepo
2010-11-17 23:25:23 +03:00
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)
merge: use labels in subrepo merge This is the last place that doesn't respect conflict labels in merge output. Teach subrepos to use subrepo merge output too.
2016-10-08 11:25:28 +03:00
(M)erge, keep (l)ocal [working copy] or keep (r)emote [destination]? 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)
merge: use labels in subrepo merge This is the last place that doesn't respect conflict labels in merge output. Teach subrepos to use subrepo merge output too.
2016-10-08 11:25:28 +03:00
(M)erge, keep (l)ocal [working copy] or keep (r)emote [destination]? 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)
merge: use labels in subrepo merge This is the last place that doesn't respect conflict labels in merge output. Teach subrepos to use subrepo merge output too.
2016-10-08 11:25:28 +03:00
(M)erge, keep (l)ocal [working copy] or keep (r)emote [destination]? 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)
merge: use labels in subrepo merge This is the last place that doesn't respect conflict labels in merge output. Teach subrepos to use subrepo merge output too.
2016-10-08 11:25:28 +03:00
(M)erge, keep (l)ocal [working copy] or keep (r)emote [destination]? 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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A dir/epsilon.py
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm 'Add dir/epsilon.py'
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
$ 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
subrepo: don't abort in add when non-hg subrepos are present (issue4513) This change should have been part of a5602d49abba.
2015-01-28 04:57:43 +03:00
$ hg add .
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
adding a
subrepo: don't abort in add when non-hg subrepos are present (issue4513) This change should have been part of a5602d49abba.
2015-01-28 04:57:43 +03:00
$ hg ci -m adda
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 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
$ 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'
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.
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ hg ci --subrepos -m cleanup | filter_svn_output
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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
Sending obstruct/other
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 7.
At revision 7.
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn mkdir -qm "baseline" $SVNREPOURL/trunk
$ svn copy -qm "initial branch" $SVNREPOURL/trunk $SVNREPOURL/branch
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
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm 'Something old'
$ svn rm -qm "remove branch" $SVNREPOURL/branch
$ svn copy -qm "recreate branch" $SVNREPOURL/trunk $SVNREPOURL/branch
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
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm 'Something new'
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 ..
$ 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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A 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
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
progress: get the extremely verbose output out of default debug When the progress extension is not enabled, each call to 'ui.progress' used to issue a debug message. This results is a very verbose output and often redundant in tests. Dropping it makes tests less volatile to factor they do not meant to test. We had to alter the sed trick in 'test-rename-merge2.t'. Sed is used to drop all output from a certain point and hidding the progress output remove its anchor. So we anchor on something else.
2015-05-10 09:40:40 +03:00
$ hg archive -S ../archive-all --debug --config progress.debug=true
ui: deprecate ui.progress Summary: Remove ui.progress as a method of updating progress. All progress bars now go through new-style progress bars. This also splits out the rendering of progress bars from the reporting of progress. All tests are updated to use new-style debug progress bars, which simply report the position of the progress bar. Rendering of progress bars will be tested separately once the progress bar engine has been rewritten. Reviewed By: quark-zju Differential Revision: D7329488 fbshipit-source-id: 14f8ab67365ddd98b74986aa25d9abc7a0546144
2018-03-21 23:49:51 +03:00
progress: archiving: .hgsub 1/2 files (50.00%)
progress: archiving: .hgsubstate 2/2 files (100.00%)
progress: archiving (end)
progress: archiving (obstruct): 1/1 files (100.00%)
progress: archiving (obstruct) (end)
progress: archiving (recreated): 1/1 files (100.00%)
progress: archiving (recreated) (end)
progress: archiving (s): 1/2 files (50.00%)
progress: archiving (s): 2/2 files (100.00%)
progress: archiving (s) (end)
subrepo: fix default implementation of forget() (issue3404)
2012-04-27 13:02:16 +04:00
progress: get the extremely verbose output out of default debug When the progress extension is not enabled, each call to 'ui.progress' used to issue a debug message. This results is a very verbose output and often redundant in tests. Dropping it makes tests less volatile to factor they do not meant to test. We had to alter the sed trick in 'test-rename-merge2.t'. Sed is used to drop all output from a certain point and hidding the progress output remove its anchor. So we anchor on something else.
2015-05-10 09:40:40 +03:00
$ hg archive -S ../archive-exclude --debug --config progress.debug=true -X **old
ui: deprecate ui.progress Summary: Remove ui.progress as a method of updating progress. All progress bars now go through new-style progress bars. This also splits out the rendering of progress bars from the reporting of progress. All tests are updated to use new-style debug progress bars, which simply report the position of the progress bar. Rendering of progress bars will be tested separately once the progress bar engine has been rewritten. Reviewed By: quark-zju Differential Revision: D7329488 fbshipit-source-id: 14f8ab67365ddd98b74986aa25d9abc7a0546144
2018-03-21 23:49:51 +03:00
progress: archiving: .hgsub 1/2 files (50.00%)
progress: archiving: .hgsubstate 2/2 files (100.00%)
progress: archiving (end)
progress: archiving (obstruct): 1/1 files (100.00%)
progress: archiving (obstruct) (end)
progress: archiving (s): 1/2 files (50.00%)
progress: archiving (s): 2/2 files (100.00%)
progress: archiving (s) (end)
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
$ 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
$ hg forget 'notafile*'
tests: add a substitution for ENOENT/ERROR_FILE_NOT_FOUND messages Automatic replacement seems better than trying to figure out a check-code rule. I didn't bother looking to see why the error message and file name is reversed in the annotate and histedit tests, based on Windows or not. I originally had this as a list of tuples, conditional on the platform. But there are a couple of 'No such file or directory' messages emitted by Mercurial itself, so unconditional is required for stability. There are also several variants of what I assume is 'connection refused' and 'unknown host' in test-clone.t and test-clonebundles.t for Docker, FreeBSD jails, etc. Yes, these are handled by (re) tags, but maybe it would be better to capture those strings in order to avoid whack-a-mole in future tests. All of this points to using a dictionary containing one or more strings-to-be-replaced values.
2017-12-03 03:33:34 +03:00
notafile*: $ENOENT$
subrepo: fix default implementation of forget() (issue3404)
2012-04-27 13:02:16 +04:00
[1]
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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A trunk/subdir
A trunk/subdir/a
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
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm addsubdir
$ svn cp -qm 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
$ 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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A subdir/a
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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A .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
A sub
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
A sub/.hg
A sub/.hg/hgrc
tests: suppress verbose output of svn transaction Subversion 1.9 shows more verbose messages than 1.8 and the tests fail because of them. These outputs are not important in our tests, so let's suppress them by -q or grep -v.
2015-09-26 09:20:32 +03:00
$ svn ci -qm 'add .hg/hgrc to be sanitized at hg update'
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
$ 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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
warning: removing potentially hostile 'hgrc' in '$TESTTMP/sub/tc/s/.hg'
warning: removing potentially hostile 'hgrc' in '$TESTTMP/sub/tc/s/sub/.hg'
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 ../..
subrepo: add tests for svn rogue ssh urls (SEC) 'ssh://' has an exploit that will pass the url blindly to the ssh command, allowing a malicious person to have a subrepo with '-oProxyCommand' which could run arbitrary code on a user's machine. In addition, at least on Windows, a pipe '|' is able to execute arbitrary commands. When this happens, let's throw a big abort into the user's face so that they can inspect what's going on.
2017-08-01 02:44:17 +03:00
SEC: test for ssh exploit
$ hg init ssh-vuln
$ cd ssh-vuln
$ echo "s = [svn]$SVNREPOURL/src" >> .hgsub
$ svn co --quiet "$SVNREPOURL"/src s
$ hg add .hgsub
$ hg ci -m1
$ echo "s = [svn]svn+ssh://-oProxyCommand=touch%20owned%20nested" > .hgsub
$ hg ci -m2
$ cd ..
$ hg clone ssh-vuln ssh-vuln-clone
updating to branch default
abort: potentially unsafe url: 'svn+ssh://-oProxyCommand=touch owned nested' (in subrepository "s")
[255]
also check that a percent encoded '-' (%2D) doesn't work
$ cd ssh-vuln
$ echo "s = [svn]svn+ssh://%2DoProxyCommand=touch%20owned%20nested" > .hgsub
$ hg ci -m3
$ cd ..
$ rm -r ssh-vuln-clone
$ hg clone ssh-vuln ssh-vuln-clone
updating to branch default
abort: potentially unsafe url: 'svn+ssh://-oProxyCommand=touch owned nested' (in subrepository "s")
[255]
also check that hiding the attack in the username doesn't work:
$ cd ssh-vuln
$ echo "s = [svn]svn+ssh://%2DoProxyCommand=touch%20owned%20foo@example.com/nested" > .hgsub
$ hg ci -m3
$ cd ..
$ rm -r ssh-vuln-clone
$ hg clone ssh-vuln ssh-vuln-clone
updating to branch default
abort: potentially unsafe url: 'svn+ssh://-oProxyCommand=touch owned foo@example.com/nested' (in subrepository "s")
[255]
Reference in New Issue Copy Permalink