facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 07:17:55 +03:00
Code Issues Projects Releases Wiki Activity
1c506fb28b
sapling/tests/test-clone.t

1257 lines
32 KiB
Perl
Raw Normal View History

tests: unify test-clone
2010-08-10 15:21:28 +04:00
Prepare repo a:
tests: remove redundant mkdir There are still many tests that check that a bare 'hg init' initializes the current directory.
2011-04-19 14:04:44 +04:00
$ hg init a
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ cd a
$ echo a > a
$ hg add a
$ hg commit -m test
$ echo first line > b
$ hg add b
Create a non-inlined filelog:
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 'file("data1", "wb").write("".join("%s\n" % x for x in range(10000)))'
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ for j in 0 1 2 3 4 5 6 7 8 9; do
> cat data1 >> b
> hg commit -m test
> done
List files in store/data (should show a 'b.d'):
$ for i in .hg/store/data/*; do
> echo $i
> done
.hg/store/data/a.i
.hg/store/data/b.d
.hg/store/data/b.i
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
2014-08-22 03:05:29 +04:00
Trigger branchcache creation:
$ hg branches
default 10:a7949464abda
$ ls .hg/cache
branch2-served
tests: add per-line output conditionals for Windows
2017-04-06 06:44:22 +03:00
checkisexec (execbit !)
checklink (symlink !)
checklink-target (symlink !)
checknoexec (execbit !)
branchmap: use revbranchcache when updating branch map The revbranchcache is read on demand before it will be used for updating the branch map. It is written back when the branchmap is written and it will thus use the same locking as branchmap. The revbranchcache instance is short-lived; it is only stored in the branchmap from .update() is invoked and until .write() is invoked. Branchmap already assume that the repo is locked in that case. The use of revbranchcache for branch map updates will make sure that the revbranchcache "always" is kept up-to-date. The perfbranchmap benchmark is somewhat bogus, especially when we can see that the caching makes a significant difference between the realistic case of a first run and the rare case of rerunning it with a full cache. Here are some 'base' numbers on mozilla-central: Before: ! wall 6.912745 comb 6.910000 user 6.840000 sys 0.070000 (best of 3) After - initial, cache is empty: ! wall 7.792569 comb 7.790000 user 7.720000 sys 0.070000 (best of 3) After - cache is full: ! wall 0.879688 comb 0.880000 user 0.870000 sys 0.010000 (best of 4) The overhead when running with empty cache comes from checking, missing and updating it every time. Most of the performance improvement comes from not having to extract the branch info from the changelog. The last doubling of performance comes from no longer having to convert all branch names to local encoding but reuse the few already converted branch names. On the hg repo: Before: ! wall 0.715703 comb 0.710000 user 0.710000 sys 0.000000 (best of 14) After: ! wall 0.105489 comb 0.110000 user 0.110000 sys 0.000000 (best of 87)
2015-01-08 02:01:03 +03:00
rbc-names-v1
rbc-revs-v1
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
2014-08-22 03:05:29 +04:00
tests: unify test-clone
2010-08-10 15:21:28 +04:00
Default operation:
$ hg clone . ../b
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ../b
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
2014-08-22 03:05:29 +04:00
Ensure branchcache got copied over:
$ ls .hg/cache
branch2-served
tests: add per-line output conditionals for Windows
2017-04-06 06:44:22 +03:00
checkisexec (execbit !)
checklink (symlink !)
checklink-target (symlink !)
local-clone: also copy revs-branch-cache files This cache provides a large speedup for some repositories. Keeping it around is valuable.
2017-05-25 13:05:33 +03:00
rbc-names-v1
rbc-revs-v1
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
2014-08-22 03:05:29 +04:00
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ cat a
a
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
2 files, 11 changesets, 11 total revisions
test-clone.t: add basic cases for destination '' The case $ hg clone a '' already aborted before c1e68cd8cfa8, whereas $ hg clone --pull a '' tripped the fixed issue2528. Both basic cases are expected to fail with an abort.
2010-12-01 06:21:47 +03:00
Invalid dest '' must abort:
$ hg clone . ''
localrepo: use the path relative to "self.vfs" instead of "path" argument As a part of migration to vfs, this patch uses "self.root", which can be recognized as the path relative to "self.vfs", instead of "path" argument. This fix allows to make invocations of "util.makedirs()" and "os.path.exists()" while ensuring repository directory in "localrepository.__init__()" ones indirectly via vfs. But this fix also raises issue 2528: "hg clone" with empty destination. "path" argument is empty in many cases, so this issue can't be fixed in the view of "localrepository.__init__()". Before this patch, it is fixed by empty-ness check ("not name") of exception handler in "util.makedirs()". try: os.mkdir(name) except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT or not name: raise This requires "localrepository.__init__()" to invoke "util.makedirs()" with "path" instead of "self.root", because empty "path" is treated as "current directory" and "self.root" becomes valid path. But "hg clone" with empty destination can be detected also in "hg.clone()" before "localrepository.__init__()" invocation, so this patch re-fixes issue2528 by checking it in "hg.clone()".
2012-07-06 13:45:27 +04:00
abort: empty destination path is not valid
test-clone.t: add basic cases for destination '' The case $ hg clone a '' already aborted before c1e68cd8cfa8, whereas $ hg clone --pull a '' tripped the fixed issue2528. Both basic cases are expected to fail with an abort.
2010-12-01 06:21:47 +03:00
[255]
tests: unify test-clone
2010-08-10 15:21:28 +04:00
No update, with debug option:
tests: introduce hghave hardlinks Some tests can't be run on FAT filesystems because it doesn't support hardlinks.
2012-06-15 02:02:27 +04:00
#if hardlink
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 --debug clone -U . ../c --config progress.debug=true
clone: add progress support to hardlink clones (issue3059)
2015-03-14 01:28:11 +03:00
linking: 1
linking: 2
linking: 3
linking: 4
linking: 5
linking: 6
linking: 7
linking: 8
tests: unify test-clone
2010-08-10 15:21:28 +04:00
linked 8 files
tests: introduce hghave hardlinks Some tests can't be run on FAT filesystems because it doesn't support hardlinks.
2012-06-15 02:02:27 +04:00
#else
tests: fix test-clone on vfat
2015-05-21 22:30:22 +03:00
$ hg --debug clone -U . ../c --config progress.debug=true
test-clone: fix test expectations on systems without hardlinks
2015-04-04 01:10:12 +03:00
linking: 1
copying: 2
copying: 3
copying: 4
copying: 5
copying: 6
copying: 7
copying: 8
tests: introduce hghave hardlinks Some tests can't be run on FAT filesystems because it doesn't support hardlinks.
2012-06-15 02:02:27 +04:00
copied 8 files
#endif
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ cd ../c
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
2014-08-22 03:05:29 +04:00
Ensure branchcache got copied over:
$ ls .hg/cache
branch2-served
local-clone: also copy revs-branch-cache files This cache provides a large speedup for some repositories. Keeping it around is valuable.
2017-05-25 13:05:33 +03:00
rbc-names-v1
rbc-revs-v1
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
2014-08-22 03:05:29 +04:00
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ cat a 2>/dev/null || echo "a not present"
a not present
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
2 files, 11 changesets, 11 total revisions
Default destination:
$ mkdir ../d
$ cd ../d
$ hg clone ../a
destination directory: a
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd a
$ hg cat a
a
$ cd ../..
Check that we drop the 'file:' from the path before writing the .hgrc:
$ hg clone file:a e
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ grep 'file:' e/.hg/hgrc
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[1]
tests: unify test-clone
2010-08-10 15:21:28 +04:00
Check that path aliases are expanded:
$ hg clone -q -U --config 'paths.foobar=a#0' foobar f
$ hg -R f showconfig paths.default
tests: add missing '(glob)'s to match '\' in paths in test output on windows
2011-11-16 06:45:14 +04:00
$TESTTMP/a#0 (glob)
tests: unify test-clone
2010-08-10 15:21:28 +04:00
Use --pull:
$ hg clone --pull a g
requesting all changes
adding changesets
adding manifests
adding file changes
added 11 changesets with 11 changes to 2 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets acb14030fe0a:a7949464abda
tests: unify test-clone
2010-08-10 15:21:28 +04:00
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg -R g verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
2 files, 11 changesets, 11 total revisions
test-clone.t: add basic cases for destination '' The case $ hg clone a '' already aborted before c1e68cd8cfa8, whereas $ hg clone --pull a '' tripped the fixed issue2528. Both basic cases are expected to fail with an abort.
2010-12-01 06:21:47 +03:00
Invalid dest '' with --pull must abort (issue2528):
$ hg clone --pull a ''
localrepo: use the path relative to "self.vfs" instead of "path" argument As a part of migration to vfs, this patch uses "self.root", which can be recognized as the path relative to "self.vfs", instead of "path" argument. This fix allows to make invocations of "util.makedirs()" and "os.path.exists()" while ensuring repository directory in "localrepository.__init__()" ones indirectly via vfs. But this fix also raises issue 2528: "hg clone" with empty destination. "path" argument is empty in many cases, so this issue can't be fixed in the view of "localrepository.__init__()". Before this patch, it is fixed by empty-ness check ("not name") of exception handler in "util.makedirs()". try: os.mkdir(name) except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT or not name: raise This requires "localrepository.__init__()" to invoke "util.makedirs()" with "path" instead of "self.root", because empty "path" is treated as "current directory" and "self.root" becomes valid path. But "hg clone" with empty destination can be detected also in "hg.clone()" before "localrepository.__init__()" invocation, so this patch re-fixes issue2528 by checking it in "hg.clone()".
2012-07-06 13:45:27 +04:00
abort: empty destination path is not valid
test-clone.t: add basic cases for destination '' The case $ hg clone a '' already aborted before c1e68cd8cfa8, whereas $ hg clone --pull a '' tripped the fixed issue2528. Both basic cases are expected to fail with an abort.
2010-12-01 06:21:47 +03:00
[255]
tests: unify test-clone
2010-08-10 15:21:28 +04:00
Clone to '.':
$ mkdir h
$ cd h
$ hg clone ../a .
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ..
*** Tests for option -u ***
Adding some more history to repo a:
$ cd a
$ hg tag ref1
$ echo the quick brown fox >a
$ hg ci -m "hacked default"
$ hg up ref1
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg branch stable
marked working directory as branch stable
branch: warn on branching
2011-12-09 00:32:44 +04:00
(branches are permanent and global, did you want a bookmark?)
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ echo some text >a
$ hg ci -m "starting branch stable"
$ hg tag ref2
$ echo some more text >a
$ hg ci -m "another change for branch stable"
$ hg up ref2
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg parents
changeset: 13:e8ece76546a6
branch: stable
tag: ref2
parent: 10:a7949464abda
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: starting branch stable
Repo a has two heads:
$ hg heads
changeset: 15:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
$ cd ..
Testing --noupdate with --updaterev (must abort):
$ hg clone --noupdate --updaterev 1 a ua
abort: cannot specify both --noupdate and --updaterev
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-clone
2010-08-10 15:21:28 +04:00
Testing clone -u:
$ hg clone -u . a ua
updating to branch stable
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has both heads:
$ hg -R ua heads
changeset: 15:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
Same revision checked out in repo a and ua:
$ hg -R a parents --template "{node|short}\n"
e8ece76546a6
$ hg -R ua parents --template "{node|short}\n"
e8ece76546a6
$ rm -r ua
Testing clone --pull -u:
$ hg clone --pull -u . a ua
requesting all changes
adding changesets
adding manifests
adding file changes
added 16 changesets with 16 changes to 3 files (+1 heads)
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets acb14030fe0a:0aae7cf88f0d
tests: unify test-clone
2010-08-10 15:21:28 +04:00
updating to branch stable
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has both heads:
$ hg -R ua heads
changeset: 15:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
Same revision checked out in repo a and ua:
$ hg -R a parents --template "{node|short}\n"
e8ece76546a6
$ hg -R ua parents --template "{node|short}\n"
e8ece76546a6
$ rm -r ua
Testing clone -u <branch>:
$ hg clone -u stable a ua
updating to branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has both heads:
$ hg -R ua heads
changeset: 15:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
Branch 'stable' is checked out:
$ hg -R ua parents
changeset: 15:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
$ rm -r ua
Testing default checkout:
$ hg clone a ua
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has both heads:
$ hg -R ua heads
changeset: 15:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
Branch 'default' is checked out:
$ hg -R ua parents
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
test-clone.t: check that branch "@" is not automatically checked out This verifies that 7b0bf61addc9 fixes the second problem mentioned in issue3677.
2012-10-26 15:20:44 +04:00
Test clone with a branch named "@" (issue3677)
tests: unify test-clone
2010-08-10 15:21:28 +04:00
test-clone.t: check that branch "@" is not automatically checked out This verifies that 7b0bf61addc9 fixes the second problem mentioned in issue3677.
2012-10-26 15:20:44 +04:00
$ hg -R ua branch @
marked working directory as branch @
$ hg -R ua commit -m 'created branch @'
$ hg clone ua atbranch
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg -R atbranch heads
changeset: 16:798b6d97153e
branch: @
tag: tip
parent: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: created branch @
changeset: 15:0aae7cf88f0d
branch: stable
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
$ hg -R atbranch parents
changeset: 12:f21241060d6a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: hacked default
$ rm -r ua atbranch
tests: unify test-clone
2010-08-10 15:21:28 +04:00
Testing #<branch>:
$ hg clone -u . a#stable ua
adding changesets
adding manifests
adding file changes
added 14 changesets with 14 changes to 3 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets acb14030fe0a:0aae7cf88f0d
tests: unify test-clone
2010-08-10 15:21:28 +04:00
updating to branch stable
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has branch 'stable' and 'default' (was changed in fd511e9eeea6):
$ hg -R ua heads
changeset: 13:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 10:a7949464abda
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: test
Same revision checked out in repo a and ua:
$ hg -R a parents --template "{node|short}\n"
e8ece76546a6
$ hg -R ua parents --template "{node|short}\n"
e8ece76546a6
$ rm -r ua
Testing -u -r <branch>:
$ hg clone -u . -r stable a ua
adding changesets
adding manifests
adding file changes
added 14 changesets with 14 changes to 3 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets acb14030fe0a:0aae7cf88f0d
tests: unify test-clone
2010-08-10 15:21:28 +04:00
updating to branch stable
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has branch 'stable' and 'default' (was changed in fd511e9eeea6):
$ hg -R ua heads
changeset: 13:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 10:a7949464abda
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: test
Same revision checked out in repo a and ua:
$ hg -R a parents --template "{node|short}\n"
e8ece76546a6
$ hg -R ua parents --template "{node|short}\n"
e8ece76546a6
$ rm -r ua
Testing -r <branch>:
$ hg clone -r stable a ua
adding changesets
adding manifests
adding file changes
added 14 changesets with 14 changes to 3 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets acb14030fe0a:0aae7cf88f0d
tests: unify test-clone
2010-08-10 15:21:28 +04:00
updating to branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has branch 'stable' and 'default' (was changed in fd511e9eeea6):
$ hg -R ua heads
changeset: 13:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
changeset: 10:a7949464abda
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: test
Branch 'stable' is checked out:
$ hg -R ua parents
changeset: 13:0aae7cf88f0d
branch: stable
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
$ rm -r ua
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue2267: Error in 1.6 hg.py: TypeError: 'NoneType' object is not
iterable in addbranchrevs()
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ cat <<EOF > simpleclone.py
> from mercurial import ui, hg
ui: factor out ui.load() to create a ui without loading configs (API) This allows us to write doctests depending on a ui object, but not on global configs. ui.load() is a class method so we can do wsgiui.load(). All ui() calls but for doctests are replaced with ui.load(). Some of them could be changed to not load configs later.
2016-10-22 08:35:10 +03:00
> myui = ui.ui.load()
tests: unify test-clone
2010-08-10 15:21:28 +04:00
> repo = hg.repository(myui, 'a')
hg: add opts argument to clone for internal remoteui
2011-06-08 20:24:33 +04:00
> hg.clone(myui, {}, repo, dest="ua")
tests: unify test-clone
2010-08-10 15:21:28 +04:00
> EOF
cleanup: use $PYTHON to run python in many more tests Spotted one of these, then wrote a check-code rule that caught them all. It will be the next change.
2017-06-20 16:45:02 +03:00
$ $PYTHON simpleclone.py
tests: unify test-clone
2010-08-10 15:21:28 +04:00
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ rm -r ua
test-clone: 0a537dab3c97 lost changes from 78317c48fc40
2010-08-13 13:12:37 +04:00
$ cat <<EOF > branchclone.py
test-clone: load extensions before doing anything This makes it possible to run this test using "--extra-config-opt=extensions.myext=" and have the extension be loaded as intended.
2012-07-12 02:34:32 +04:00
> from mercurial import ui, hg, extensions
ui: factor out ui.load() to create a ui without loading configs (API) This allows us to write doctests depending on a ui object, but not on global configs. ui.load() is a class method so we can do wsgiui.load(). All ui() calls but for doctests are replaced with ui.load(). Some of them could be changed to not load configs later.
2016-10-22 08:35:10 +03:00
> myui = ui.ui.load()
test-clone: load extensions before doing anything This makes it possible to run this test using "--extra-config-opt=extensions.myext=" and have the extension be loaded as intended.
2012-07-12 02:34:32 +04:00
> extensions.loadall(myui)
test-clone: 0a537dab3c97 lost changes from 78317c48fc40
2010-08-13 13:12:37 +04:00
> repo = hg.repository(myui, 'a')
hg: add opts argument to clone for internal remoteui
2011-06-08 20:24:33 +04:00
> hg.clone(myui, {}, repo, dest="ua", branch=["stable",])
test-clone: 0a537dab3c97 lost changes from 78317c48fc40
2010-08-13 13:12:37 +04:00
> EOF
Merge with stable
2010-08-12 20:30:24 +04:00
cleanup: use $PYTHON to run python in many more tests Spotted one of these, then wrote a check-code rule that caught them all. It will be the next change.
2017-06-20 16:45:02 +03:00
$ $PYTHON branchclone.py
test-clone: 0a537dab3c97 lost changes from 78317c48fc40
2010-08-13 13:12:37 +04:00
adding changesets
adding manifests
adding file changes
added 14 changesets with 14 changes to 3 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets acb14030fe0a:0aae7cf88f0d
test-clone: 0a537dab3c97 lost changes from 78317c48fc40
2010-08-13 13:12:37 +04:00
updating to branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ rm -r ua
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
clone: update to @ bookmark if it exists
2012-03-22 01:53:39 +04:00
Test clone with special '@' bookmark:
$ cd a
$ hg bookmark -r a7949464abda @ # branch point of stable from default
$ hg clone . ../i
clone: show status "updating to bookmark @" if bookmark @ is not on the default branch, we show updating to bookmark @ on branch <name>
2012-10-29 17:02:30 +04:00
updating to bookmark @
clone: update to @ bookmark if it exists
2012-03-22 01:53:39 +04:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -i ../i
a7949464abda
clone: show status "updating to bookmark @" if bookmark @ is not on the default branch, we show updating to bookmark @ on branch <name>
2012-10-29 17:02:30 +04:00
$ rm -r ../i
$ hg bookmark -f -r stable @
$ hg bookmarks
@ 15:0aae7cf88f0d
$ hg clone . ../i
updating to bookmark @ on branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -i ../i
0aae7cf88f0d
test-clone: fix directory level c1644655c164 inserted a "cd a" but didn't restore the previous directory.
2012-10-28 17:16:16 +04:00
$ cd "$TESTTMP"
clone: update to @ bookmark if it exists
2012-03-22 01:53:39 +04:00
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
Testing failures:
$ mkdir fail
$ cd fail
No local source
$ hg clone a b
abort: repository a not found!
[255]
No remote source
tests: add "(glob)" for l10n messages in test-clone.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#if windows
tests: use LOCALIP This patch replaces hardcoded 127.0.0.1 with $LOCALIP in all tests. Till now, the IPv6 series should make tests pass on common IPv6 systems where the local device has the address "::1" and the hostname "localhost" resolves to "::1".
2017-02-16 20:38:52 +03:00
$ hg clone http://$LOCALIP:3121/a b
tests: add "(glob)" for l10n messages in test-clone.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
abort: error: * (glob)
[255]
#else
tests: use LOCALIP This patch replaces hardcoded 127.0.0.1 with $LOCALIP in all tests. Till now, the IPv6 series should make tests pass on common IPv6 systems where the local device has the address "::1" and the hostname "localhost" resolves to "::1".
2017-02-16 20:38:52 +03:00
$ hg clone http://$LOCALIP:3121/a b
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
abort: error: *refused* (glob)
[255]
tests: add "(glob)" for l10n messages in test-clone.t for Windows This patch follows the style of other tests avoiding same kind of issue.
2014-10-20 17:08:08 +04:00
#endif
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
$ rm -rf b # work around bug with http clone
tests: skip tests that require not having root (issue4089) This adds a new root hghave to test against. Almost all of these are a subset of unix-permissions, but that is also used for checking exec bit handling.
2013-11-15 04:07:43 +04:00
#if unix-permissions no-root
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
Inaccessible source
$ mkdir a
$ chmod 000 a
$ hg clone a b
abort: repository a not found!
[255]
Inaccessible destination
$ hg init b
$ cd b
$ hg clone . ../a
dispatch: show empty filename in OSError aborts Mercurial would sometimes exit with: abort: No such file or directory where str of the actual OSError exception was the more helpful: [Errno 2] No such file or directory: '' The exception will now always show the filename and quote it: abort: No such file or directory: ''
2013-01-07 05:00:29 +04:00
abort: Permission denied: '../a'
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
[255]
$ cd ..
$ chmod 700 a
$ rm -r a b
#endif
tests: change odd uses of 'if hghave' to #if
2012-06-10 15:01:40 +04:00
#if fifo
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
Source of wrong type
tests: change odd uses of 'if hghave' to #if
2012-06-10 15:01:40 +04:00
$ mkfifo a
$ hg clone a b
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
abort: repository a not found!
tests: change odd uses of 'if hghave' to #if
2012-06-10 15:01:40 +04:00
[255]
$ rm a
#endif
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
Default destination, same directory
$ hg init q
$ hg clone q
destination directory: q
abort: destination 'q' is not empty
[255]
destination directory not empty
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ mkdir a
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
$ echo stuff > a/a
$ hg clone q a
abort: destination 'a' is not empty
[255]
tests: skip tests that require not having root (issue4089) This adds a new root hghave to test against. Almost all of these are a subset of unix-permissions, but that is also used for checking exec bit handling.
2013-11-15 04:07:43 +04:00
#if unix-permissions no-root
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
leave existing directory in place after clone failure
$ hg init c
$ cd c
$ echo c > c
$ hg commit -A -m test
adding c
$ chmod -rx .hg/store/data
$ cd ..
$ mkdir d
$ hg clone c d 2> err
[255]
$ test -d d
$ test -d d/.hg
[1]
fix trivial spelling errors
2012-08-16 00:38:42 +04:00
re-enable perm to allow deletion
tests: roll test-clone-failure.t into test-clone.t
2012-06-04 21:05:22 +04:00
$ chmod +rx c/.hg/store/data
#endif
$ cd ..
hg: use "os.path.join()" to join path components which may be empty (issue4203) Changset 39a4d61c40d6 rewriting "hg.copystore()" with vfs uses 'dstbase + "/lock"' instead of "os.path.join()", because target files given from "store.copyfiles()" already uses "/" as path separator But in the repository using revlog format 0, "dstbase" becomes empty ("data" directory is located under ".hg" directly), and 'dstbase + "/lock"' is treated as "/lock": in almost all cases, write access to "/lock" causes "permission denied". This patch uses "os.path.join()" to join path components which may be empty in "hg.copystore()".
2014-03-25 14:34:17 +04:00
Test clone from the repository in (emulated) revlog format 0 (issue4203):
$ mkdir issue4203
$ mkdir -p src/.hg
$ echo foo > src/foo
$ hg -R src add src/foo
$ hg -R src commit -m '#0'
$ hg -R src log -q
0:e1bab28bca43
$ hg clone -U -q src dst
$ hg -R dst log -q
0:e1bab28bca43
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
Create repositories to test auto sharing functionality
$ cat >> $HGRCPATH << EOF
> [extensions]
> share=
> EOF
$ hg init empty
$ hg init source1a
$ cd source1a
$ echo initial1 > foo
$ hg -q commit -A -m initial
$ echo second > foo
$ hg commit -m second
$ cd ..
$ hg init filteredrev0
$ cd filteredrev0
$ cat >> .hg/hgrc << EOF
> [experimental]
config: use 'experimental.evolution.create-markers' Extract 'experimental.evolution' = createmarkers as 'experimental.evolution.createmarkers'. We keep the new option in the 'experimental.evolution' namespace in order to stay coherent with other options ('experimental.evolution.bundle-obsmarker' and 'experimental.evolution.track-operation') ease the renaming as possibly 'evolution.createmarkers'. Differential Revision: https://phab.mercurial-scm.org/D1149
2017-09-28 20:19:06 +03:00
> evolution.createmarkers=True
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
> EOF
$ echo initial1 > foo
$ hg -q commit -A -m initial0
$ hg -q up -r null
$ echo initial2 > foo
$ hg -q commit -A -m initial1
$ hg debugobsolete c05d5c47a5cf81401869999f3d05f7d699d2b29a e082c1832e09a7d1e78b7fd49a592d372de854c8
debugobsolete: also report the number of obsoleted changesets This seems useful to have the number of obsoleted changesets when calling debugobsolete.
2017-07-16 03:33:14 +03:00
obsoleted 1 changesets
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ cd ..
$ hg -q clone --pull source1a source1b
$ cd source1a
$ hg bookmark bookA
$ echo 1a > foo
$ hg commit -m 1a
$ cd ../source1b
$ hg -q up -r 0
$ echo head1 > foo
$ hg commit -m head1
created new head
$ hg bookmark head1
$ hg -q up -r 0
$ echo head2 > foo
$ hg commit -m head2
created new head
$ hg bookmark head2
$ hg -q up -r 0
$ hg branch branch1
marked working directory as branch branch1
(branches are permanent and global, did you want a bookmark?)
$ echo branch1 > foo
$ hg commit -m branch1
$ hg -q up -r 0
$ hg branch branch2
marked working directory as branch branch2
$ echo branch2 > foo
$ hg commit -m branch2
$ cd ..
$ hg init source2
$ cd source2
$ echo initial2 > foo
$ hg -q commit -A -m initial2
$ echo second > foo
$ hg commit -m second
hg: use "os.path.join()" to join path components which may be empty (issue4203) Changset 39a4d61c40d6 rewriting "hg.copystore()" with vfs uses 'dstbase + "/lock"' instead of "os.path.join()", because target files given from "store.copyfiles()" already uses "/" as path separator But in the repository using revlog format 0, "dstbase" becomes empty ("data" directory is located under ".hg" directly), and 'dstbase + "/lock"' is treated as "/lock": in almost all cases, write access to "/lock" causes "permission denied". This patch uses "os.path.join()" to join path components which may be empty in "hg.copystore()".
2014-03-25 14:34:17 +04:00
$ cd ..
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
Clone with auto share from an empty repo should not result in share
$ mkdir share
$ hg --config share.pool=share clone empty share-empty
(not using pooled storage: remote appears to be empty)
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ ls share
$ test -d share-empty/.hg/store
$ test -f share-empty/.hg/sharedpath
[1]
Clone with auto share from a repo with filtered revision 0 should not result in share
$ hg --config share.pool=share clone filteredrev0 share-filtered
(not using pooled storage: unable to resolve identity of remote)
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets e082c1832e09
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Clone from repo with content should result in shared store being created
$ hg --config share.pool=share clone source1a share-dest1a
(sharing from new pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
requesting all changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 1 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets b5f04eac9d8f:e5bfe23c0b47
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
searching for changes
no changes found
adding remote bookmark bookA
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
The shared repo should have been created
$ ls share
b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1
The destination should point to it
$ cat share-dest1a/.hg/sharedpath; echo
test-clone: fix globs for Windows
2015-07-21 05:44:53 +03:00
$TESTTMP/share/b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1/.hg (glob)
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
The destination should have bookmarks
$ hg -R share-dest1a bookmarks
bookA 2:e5bfe23c0b47
The default path should be the remote, not the share
$ hg -R share-dest1a config paths.default
test-clone: fix globs for Windows
2015-07-21 05:44:53 +03:00
$TESTTMP/source1a (glob)
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
Clone with existing share dir should result in pull + share
$ hg --config share.pool=share clone source1b share-dest1b
(sharing from existing pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
searching for changes
adding changesets
adding manifests
adding file changes
added 4 changesets with 4 changes to 1 files (+4 heads)
adding remote bookmark head1
adding remote bookmark head2
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets 4a8dc1ab4c13:6bacf4683960
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ ls share
b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1
$ cat share-dest1b/.hg/sharedpath; echo
test-clone: fix globs for Windows
2015-07-21 05:44:53 +03:00
$TESTTMP/share/b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1/.hg (glob)
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
We only get bookmarks from the remote, not everything in the share
$ hg -R share-dest1b bookmarks
head1 3:4a8dc1ab4c13
head2 4:99f71071f117
Default path should be source, not share.
$ hg -R share-dest1b config paths.default
hg: set default path correctly when doing a clone+share (issue5378) Before, if performing a clone+share from a repo that was itself using shared storage, the share code would copy paths.default from the underlying repo being shared, not from the source given by the user. This patch teaches hg.clonewithshare to resolve paths.default and pass it to share so it can be written to the hgrc accordingly.
2016-10-03 08:34:40 +03:00
$TESTTMP/source1b (glob)
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
Checked out revision should be head of default branch
$ hg -R share-dest1b log -r .
changeset: 4:99f71071f117
bookmark: head2
parent: 0:b5f04eac9d8f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: head2
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
Clone from unrelated repo should result in new share
$ hg --config share.pool=share clone source2 share-dest2
(sharing from new pooled repository 22aeff664783fd44c6d9b435618173c118c3448e)
requesting all changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets 22aeff664783:63cf6c3dba4a
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
searching for changes
no changes found
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ ls share
22aeff664783fd44c6d9b435618173c118c3448e
b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1
remote naming mode works as advertised
$ hg --config share.pool=shareremote --config share.poolnaming=remote clone source1a share-remote1a
(sharing from new pooled repository 195bb1fcdb595c14a6c13e0269129ed78f6debde)
requesting all changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 1 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets b5f04eac9d8f:e5bfe23c0b47
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
searching for changes
no changes found
adding remote bookmark bookA
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ ls shareremote
195bb1fcdb595c14a6c13e0269129ed78f6debde
$ hg --config share.pool=shareremote --config share.poolnaming=remote clone source1b share-remote1b
(sharing from new pooled repository c0d4f83847ca2a873741feb7048a45085fd47c46)
requesting all changes
adding changesets
adding manifests
adding file changes
added 6 changesets with 6 changes to 1 files (+4 heads)
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets b5f04eac9d8f:6bacf4683960
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
searching for changes
no changes found
adding remote bookmark head1
adding remote bookmark head2
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ ls shareremote
195bb1fcdb595c14a6c13e0269129ed78f6debde
c0d4f83847ca2a873741feb7048a45085fd47c46
request to clone a single revision is respected in sharing mode
$ hg --config share.pool=sharerevs clone -r 4a8dc1ab4c13 source1b share-1arev
(sharing from new pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets b5f04eac9d8f:4a8dc1ab4c13
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
no changes found
adding remote bookmark head1
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ hg -R share-1arev log -G
@ changeset: 1:4a8dc1ab4c13
| bookmark: head1
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: head1
|
o changeset: 0:b5f04eac9d8f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: initial
making another clone should only pull down requested rev
$ hg --config share.pool=sharerevs clone -r 99f71071f117 source1b share-1brev
(sharing from existing pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
adding remote bookmark head1
adding remote bookmark head2
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets 99f71071f117
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ hg -R share-1brev log -G
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
@ changeset: 2:99f71071f117
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
| bookmark: head2
| tag: tip
| parent: 0:b5f04eac9d8f
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: head2
|
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
| o changeset: 1:4a8dc1ab4c13
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
|/ bookmark: head1
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: head1
|
o changeset: 0:b5f04eac9d8f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: initial
Request to clone a single branch is respected in sharing mode
$ hg --config share.pool=sharebranch clone -b branch1 source1b share-1bbranch1
(sharing from new pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets b5f04eac9d8f:5f92a6c1a1b1
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
no changes found
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg -R share-1bbranch1 log -G
o changeset: 1:5f92a6c1a1b1
| branch: branch1
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: branch1
|
@ changeset: 0:b5f04eac9d8f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: initial
$ hg --config share.pool=sharebranch clone -b branch2 source1b share-1bbranch2
(sharing from existing pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets 6bacf4683960
hg: perform update after pulling during clone with share (issue5103) When pooled storage is enabled, `hg clone` will initialize a repo from a local repo using the store sharing mechanism then pull from the originally requested repo. Before this patch, the working directory update occurred between these steps. This meant that we would only update to revisions that were already present in the local pooled storage. This patch moves the update to after we pull from the originally requested repository so we may check out a revision that didn't yet exist locally. In other words, it makes the behavior like normal `hg clone`.
2016-02-21 04:44:29 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.
2015-07-09 02:19:09 +03:00
$ hg -R share-1bbranch2 log -G
o changeset: 2:6bacf4683960
| branch: branch2
| tag: tip
| parent: 0:b5f04eac9d8f
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: branch2
|
| o changeset: 1:5f92a6c1a1b1
|/ branch: branch1
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: branch1
|
@ changeset: 0:b5f04eac9d8f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: initial
-U is respected in share clone mode
$ hg --config share.pool=share clone -U source1a share-1anowc
(sharing from existing pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
searching for changes
no changes found
adding remote bookmark bookA
$ ls share-1anowc
hg: avoid auto sharing when the clone destination is remote Before this patch, when auto sharing is enabled, 'hg.clone()' tries to create local clone regardless of locality of the clone destination on the host, and causes failure. To avoid auto sharing when the clone destination is remote, this patch adds examination of 'islocal(dest)' before auto sharing in 'hg.clone()'. 'islocal(dest)' is examined after 'sharepool', because: - the former is more expensive than the latter - without enabling share extension, the later is always negative
2015-08-13 09:07:07 +03:00
Test that auto sharing doesn't cause failure of "hg clone local remote"
$ cd $TESTTMP
$ hg -R a id -r 0
acb14030fe0a
$ hg id -R remote -r 0
dispatch: error out on invalid -R path even if optionalrepo (issue4805) (BC) Before this patch, repo could be set to None for wrong -R. It's okay for commands that can reject repo=None, but the command server have a problem because: - it accepts repo=None for "unbound" mode - and it reenters dispatch() where repo object is created for cwd by default Test outputs are changed because the error is detected earlier. I think new message is better than ".hg not found".
2015-08-31 17:29:15 +03:00
abort: repository remote not found!
hg: avoid auto sharing when the clone destination is remote Before this patch, when auto sharing is enabled, 'hg.clone()' tries to create local clone regardless of locality of the clone destination on the host, and causes failure. To avoid auto sharing when the clone destination is remote, this patch adds examination of 'islocal(dest)' before auto sharing in 'hg.clone()'. 'islocal(dest)' is examined after 'sharepool', because: - the former is more expensive than the latter - without enabling share extension, the later is always negative
2015-08-13 09:07:07 +03:00
[255]
tests: quote $PYTHON for Windows When unquoted, MSYS sees the colon between the drive letter and path as a Unix path separator and unhelpfully splits on it, feeding only the drive letter as the command. Much chaos ensues. I vaguely remember trying to get the test runner to use /letter/path/to/exe syntax the last time this happened, without success. I doubt a check-code rule would work, since sometimes it is quoted, and sometimes the quotes are escaped.
2017-07-07 08:05:20 +03:00
$ hg --config share.pool=share -q clone -e "\"$PYTHON\" \"$TESTDIR/dummyssh\"" a ssh://user@dummy/remote
hg: avoid auto sharing when the clone destination is remote Before this patch, when auto sharing is enabled, 'hg.clone()' tries to create local clone regardless of locality of the clone destination on the host, and causes failure. To avoid auto sharing when the clone destination is remote, this patch adds examination of 'islocal(dest)' before auto sharing in 'hg.clone()'. 'islocal(dest)' is examined after 'sharepool', because: - the former is more expensive than the latter - without enabling share extension, the later is always negative
2015-08-13 09:07:07 +03:00
$ hg -R remote id -r 0
acb14030fe0a
hg: obtain lock when creating share from pooled repo (issue5104) There are race conditions between clients performing a shared clone to pooled storage: 1) Clients race to create the new shared repo in the pool directory 2) 1 client is seeding the repo in the pool directory and another goes to share it before it is fully cloned We prevent these race conditions by obtaining a lock in the pool directory that is derived from the name of the repo we will be accessing. To test this, a simple generic "lockdelay" extension has been added. The extension inserts an optional, configurable delay before or after lock acquisition. In the test, we delay 2 seconds after lock acquisition in the first process and 1 second before lock acquisition in the 2nd process. This means the first process has 1s to obtain the lock. There is a race condition here. If we encounter it in the wild, we could change the dummy extension to wait on the lock file to appear instead of relying on timing. But that's more complicated. Let's see what happens first.
2016-02-28 05:22:49 +03:00
Cloning into pooled storage doesn't race (issue5104)
$ HGPOSTLOCKDELAY=2.0 hg --config share.pool=racepool --config extensions.lockdelay=$TESTDIR/lockdelay.py clone source1a share-destrace1 > race1.log 2>&1 &
$ HGPRELOCKDELAY=1.0 hg --config share.pool=racepool --config extensions.lockdelay=$TESTDIR/lockdelay.py clone source1a share-destrace2 > race2.log 2>&1
$ wait
$ hg -R share-destrace1 log -r tip
changeset: 2:e5bfe23c0b47
bookmark: bookA
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: 1a
$ hg -R share-destrace2 log -r tip
changeset: 2:e5bfe23c0b47
bookmark: bookA
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: 1a
test-clone: fix some instability in pooled clone race condition test Healthy output (one log file mentioning "existing pooled" and one mentioning "new pooled") will now print in a stable order, but unhealthy output will print some sort of error. This reduces the flakiness of the test from 55% to 38%. My next patch makes it completely stable.
2016-10-09 11:25:22 +03:00
One repo should be new, the other should be shared from the pool. We
don't care which is which, so we just make sure we always print the
one containing "new pooled" first, then one one containing "existing
pooled".
test-clone: discard lock-related messages We can't predict where those will show up and they're not super-important for the contents of this particular test, so just drop them. Further reduces the flakiness of the test to zero.
2016-10-09 11:37:02 +03:00
$ (grep 'new pooled' race1.log > /dev/null && cat race1.log || cat race2.log) | grep -v lock
hg: obtain lock when creating share from pooled repo (issue5104) There are race conditions between clients performing a shared clone to pooled storage: 1) Clients race to create the new shared repo in the pool directory 2) 1 client is seeding the repo in the pool directory and another goes to share it before it is fully cloned We prevent these race conditions by obtaining a lock in the pool directory that is derived from the name of the repo we will be accessing. To test this, a simple generic "lockdelay" extension has been added. The extension inserts an optional, configurable delay before or after lock acquisition. In the test, we delay 2 seconds after lock acquisition in the first process and 1 second before lock acquisition in the 2nd process. This means the first process has 1s to obtain the lock. There is a race condition here. If we encounter it in the wild, we could change the dummy extension to wait on the lock file to appear instead of relying on timing. But that's more complicated. Let's see what happens first.
2016-02-28 05:22:49 +03:00
(sharing from new pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
requesting all changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 1 files
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets b5f04eac9d8f:e5bfe23c0b47
hg: obtain lock when creating share from pooled repo (issue5104) There are race conditions between clients performing a shared clone to pooled storage: 1) Clients race to create the new shared repo in the pool directory 2) 1 client is seeding the repo in the pool directory and another goes to share it before it is fully cloned We prevent these race conditions by obtaining a lock in the pool directory that is derived from the name of the repo we will be accessing. To test this, a simple generic "lockdelay" extension has been added. The extension inserts an optional, configurable delay before or after lock acquisition. In the test, we delay 2 seconds after lock acquisition in the first process and 1 second before lock acquisition in the 2nd process. This means the first process has 1s to obtain the lock. There is a race condition here. If we encounter it in the wild, we could change the dummy extension to wait on the lock file to appear instead of relying on timing. But that's more complicated. Let's see what happens first.
2016-02-28 05:22:49 +03:00
searching for changes
no changes found
adding remote bookmark bookA
tests: update test output for test written on stable branch (issue5104) The changed test lines were added in 6a934a7b8d54, which landed on stable. When this changeset merged to the default branch, the test failed because 31ed0254094d (on default but not stable) changed the order of working directory update when performing a share-based clone from pooled storage. The changes in this patch are similar to test changes in 31ed0254094d.
2016-03-04 10:11:33 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg: obtain lock when creating share from pooled repo (issue5104) There are race conditions between clients performing a shared clone to pooled storage: 1) Clients race to create the new shared repo in the pool directory 2) 1 client is seeding the repo in the pool directory and another goes to share it before it is fully cloned We prevent these race conditions by obtaining a lock in the pool directory that is derived from the name of the repo we will be accessing. To test this, a simple generic "lockdelay" extension has been added. The extension inserts an optional, configurable delay before or after lock acquisition. In the test, we delay 2 seconds after lock acquisition in the first process and 1 second before lock acquisition in the 2nd process. This means the first process has 1s to obtain the lock. There is a race condition here. If we encounter it in the wild, we could change the dummy extension to wait on the lock file to appear instead of relying on timing. But that's more complicated. Let's see what happens first.
2016-02-28 05:22:49 +03:00
test-clone: discard lock-related messages We can't predict where those will show up and they're not super-important for the contents of this particular test, so just drop them. Further reduces the flakiness of the test to zero.
2016-10-09 11:37:02 +03:00
$ (grep 'existing pooled' race1.log > /dev/null && cat race1.log || cat race2.log) | grep -v lock
hg: obtain lock when creating share from pooled repo (issue5104) There are race conditions between clients performing a shared clone to pooled storage: 1) Clients race to create the new shared repo in the pool directory 2) 1 client is seeding the repo in the pool directory and another goes to share it before it is fully cloned We prevent these race conditions by obtaining a lock in the pool directory that is derived from the name of the repo we will be accessing. To test this, a simple generic "lockdelay" extension has been added. The extension inserts an optional, configurable delay before or after lock acquisition. In the test, we delay 2 seconds after lock acquisition in the first process and 1 second before lock acquisition in the 2nd process. This means the first process has 1s to obtain the lock. There is a race condition here. If we encounter it in the wild, we could change the dummy extension to wait on the lock file to appear instead of relying on timing. But that's more complicated. Let's see what happens first.
2016-02-28 05:22:49 +03:00
(sharing from existing pooled repository b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
searching for changes
no changes found
adding remote bookmark bookA
tests: update test output for test written on stable branch (issue5104) The changed test lines were added in 6a934a7b8d54, which landed on stable. When this changeset merged to the default branch, the test failed because 31ed0254094d (on default but not stable) changed the order of working directory update when performing a share-based clone from pooled storage. The changes in this patch are similar to test changes in 31ed0254094d.
2016-03-04 10:11:33 +03:00
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
clone: add tests for unsafe ssh url (SEC)
2017-07-29 02:36:36 +03:00
SEC: check for unsafe ssh url
ssh: quote parameters using shellquote (SEC) This patch uses shellquote to quote ssh parameters more strictly to avoid shell injection.
2017-08-05 09:54:12 +03:00
$ cat >> $HGRCPATH << EOF
> [ui]
> ssh = sh -c "read l; read l; read l"
> EOF
clone: add tests for unsafe ssh url (SEC)
2017-07-29 02:36:36 +03:00
$ hg clone 'ssh://-oProxyCommand=touch${IFS}owned/path'
abort: potentially unsafe url: 'ssh://-oProxyCommand=touch${IFS}owned/path'
[255]
$ hg clone 'ssh://%2DoProxyCommand=touch${IFS}owned/path'
abort: potentially unsafe url: 'ssh://-oProxyCommand=touch${IFS}owned/path'
[255]
ssh: unban the use of pipe character in user@host:port string This vulnerability was fixed by the previous patch and there were more ways to exploit than using '|shellcmd'. So it doesn't make sense to reject only pipe character. Test cases are updated to actually try to exploit the bug. As the SSH bridge of git/svn subrepos are not managed by our code, the tests for non-hg subrepos are just removed. This may be folded into the original patches.
2017-08-07 16:22:28 +03:00
$ hg clone 'ssh://fakehost|touch%20owned/path'
abort: no suitable response from remote hg!
clone: add tests for unsafe ssh url (SEC)
2017-07-29 02:36:36 +03:00
[255]
ssh: unban the use of pipe character in user@host:port string This vulnerability was fixed by the previous patch and there were more ways to exploit than using '|shellcmd'. So it doesn't make sense to reject only pipe character. Test cases are updated to actually try to exploit the bug. As the SSH bridge of git/svn subrepos are not managed by our code, the tests for non-hg subrepos are just removed. This may be folded into the original patches.
2017-08-07 16:22:28 +03:00
$ hg clone 'ssh://fakehost%7Ctouch%20owned/path'
abort: no suitable response from remote hg!
clone: add tests for unsafe ssh url (SEC)
2017-07-29 02:36:36 +03:00
[255]
$ hg clone 'ssh://-oProxyCommand=touch owned%20foo@example.com/nonexistent/path'
abort: potentially unsafe url: 'ssh://-oProxyCommand=touch owned foo@example.com/nonexistent/path'
[255]
ssh: quote parameters using shellquote (SEC) This patch uses shellquote to quote ssh parameters more strictly to avoid shell injection.
2017-08-05 09:54:12 +03:00
#if windows
$ hg clone "ssh://%26touch%20owned%20/" --debug
running sh -c "read l; read l; read l" "&touch owned " "hg -R . serve --stdio"
sending hello command
sending between command
abort: no suitable response from remote hg!
[255]
$ hg clone "ssh://example.com:%26touch%20owned%20/" --debug
running sh -c "read l; read l; read l" -p "&touch owned " example.com "hg -R . serve --stdio"
sending hello command
sending between command
abort: no suitable response from remote hg!
[255]
#else
$ hg clone "ssh://%3btouch%20owned%20/" --debug
running sh -c "read l; read l; read l" ';touch owned ' 'hg -R . serve --stdio'
sending hello command
sending between command
abort: no suitable response from remote hg!
[255]
$ hg clone "ssh://example.com:%3btouch%20owned%20/" --debug
running sh -c "read l; read l; read l" -p ';touch owned ' example.com 'hg -R . serve --stdio'
sending hello command
sending between command
abort: no suitable response from remote hg!
[255]
#endif
$ hg clone "ssh://v-alid.example.com/" --debug
running sh -c "read l; read l; read l" v-alid\.example\.com ['"]hg -R \. serve --stdio['"] (re)
sending hello command
sending between command
abort: no suitable response from remote hg!
[255]
clone: add tests for unsafe ssh url (SEC)
2017-07-29 02:36:36 +03:00
We should not have created a file named owned - if it exists, the
attack succeeded.
$ if test -f owned; then echo 'you got owned'; fi
fsmonitor: warn when fsmonitor could be used fsmonitor can significantly speed up operations on large working directories. But fsmonitor isn't enabled by default, so naive users may not realize there is a potential to make Mercurial faster. This commit introduces a warning to working directory updates when fsmonitor could be used. The following conditions must be met: * Working directory is previously empty * New working directory adds >= N files (currently 50,000) * Running on Linux or MacOS * fsmonitor not enabled * Warning not disabled via config override Because of the empty working directory restriction, most users will only see this warning during `hg clone` (assuming very few users actually do an `hg up null`). The addition of a warning may be considered a BC change. However, clone has printed warnings before. Until recently, Mercurial printed a warning with the server's certificate fingerprint when it wasn't explicitly trusted for example. The warning goes to stderr. So it shouldn't interfere with scripts parsing meaningful output. The OS restriction was on the advice of Facebook engineers, who only feel confident with watchman's stability on the supported platforms. .. feature:: Print warning when fsmonitor isn't being used on a large repository Differential Revision: https://phab.mercurial-scm.org/D894
2017-10-18 23:57:15 +03:00
Cloning without fsmonitor enabled does not print a warning for small repos
$ hg clone a fsmonitor-default
updating to bookmark @ on branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Lower the warning threshold to simulate a large repo
$ cat >> $HGRCPATH << EOF
> [fsmonitor]
> warn_update_file_count = 2
> EOF
We should see a warning about no fsmonitor on supported platforms
#if linuxormacos no-fsmonitor
$ hg clone a nofsmonitor
updating to bookmark @ on branch stable
(warning: large working directory being used without fsmonitor enabled; enable fsmonitor to improve performance; see "hg help -e fsmonitor")
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
#else
$ hg clone a nofsmonitor
updating to bookmark @ on branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
#endif
We should not see warning about fsmonitor when it is enabled
#if fsmonitor
$ hg clone a fsmonitor-enabled
updating to bookmark @ on branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
#endif
We can disable the fsmonitor warning
$ hg --config fsmonitor.warn_when_unused=false clone a fsmonitor-disable-warning
updating to bookmark @ on branch stable
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Loaded fsmonitor but disabled in config should still print warning
#if linuxormacos fsmonitor
$ hg --config fsmonitor.mode=off clone a fsmonitor-mode-off
updating to bookmark @ on branch stable
(warning: large working directory being used without fsmonitor enabled; enable fsmonitor to improve performance; see "hg help -e fsmonitor") (fsmonitor !)
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
#endif
Warning not printed if working directory isn't empty
$ hg -q clone a fsmonitor-update
(warning: large working directory being used without fsmonitor enabled; enable fsmonitor to improve performance; see "hg help -e fsmonitor") (?)
$ cd fsmonitor-update
$ hg up acb14030fe0a
1 files updated, 0 files merged, 2 files removed, 0 files unresolved
(leaving bookmark @)
$ hg up cf0fe1914066
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
`hg update` from null revision also prints
$ hg up null
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
#if linuxormacos no-fsmonitor
$ hg up cf0fe1914066
(warning: large working directory being used without fsmonitor enabled; enable fsmonitor to improve performance; see "hg help -e fsmonitor")
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
#else
$ hg up cf0fe1914066
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
#endif
$ cd ..
Reference in New Issue Copy Permalink