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

1093 lines
28 KiB
Perl
Raw Normal View History

test-helpers: add a helper to run test using chg Summary: The helper could be used in individual tests to enable chg if chg exists. This allows us to have more precise control on what tests to use chg instead of using a global flag in run-tests.py. This makes certain tests containing many hg commands much faster. For example, `test-revset.t` took 99 seconds before: % ./run-tests.py test-revset.t --time . # Ran 1 tests, 0 skipped, 0 failed. # Producing time report start end cuser csys real Test 0.000 99.990 86.410 12.000 99.990 test-revset.t And 10 seconds after: % ./run-tests.py test-revset.t --time . # Ran 1 tests, 0 skipped, 0 failed. # Producing time report start end cuser csys real Test 0.000 10.080 0.380 0.130 10.080 test-revset.t Also enable it for some other tests. Note the whitelist is not complete. We probably want to whitelist more tests in the future. The feature could be opted out by deleting `contrib/chg/chg`. Reviewed By: phillco Differential Revision: D6767036 fbshipit-source-id: 8220cf408aa198d5d8e2ca5127ca60e2070d3444
2018-01-23 23:09:16 +03:00
$ . helpers-usechg.sh
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
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:
util: skip checkexec or checklink for wider file systems Summary: D9328199 made them skip eden mounts. This diff expands the whitelist to other common filesystems. Reviewed By: wez Differential Revision: D9416599 fbshipit-source-id: 5f1dddf5a181833a2fa6e0954c2579bb5adcd170
2018-08-21 22:19:45 +03:00
$ ls .hg/cache | grep -v check
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
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
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
ui: deprecate ui.progress Summary: Remove ui.progress as a method of updating progress. All progress bars now go through new-style progress bars. This also splits out the rendering of progress bars from the reporting of progress. All tests are updated to use new-style debug progress bars, which simply report the position of the progress bar. Rendering of progress bars will be tested separately once the progress bar engine has been rewritten. Reviewed By: quark-zju Differential Revision: D7329488 fbshipit-source-id: 14f8ab67365ddd98b74986aa25d9abc7a0546144
2018-03-21 23:49:51 +03:00
progress: linking: 1
progress: linking: 2
progress: linking: 3
progress: linking: 4
progress: linking: 5
progress: linking: 6
progress: linking: 7
progress: linking: 8
progress: linking (end)
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: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
$TESTTMP/a#0
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
$ hg bookmark stable
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
(leaving bookmark stable)
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ hg parents
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 13:7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 15:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to branch default
tests: unify test-clone
2010-08-10 15:21:28 +04:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has both heads:
$ hg -R ua heads
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 15:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ hg -R ua parents --template "{node|short}\n"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ 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)
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
new changesets acb14030fe0a:7b0a8591eda2
updating to branch default
tests: unify test-clone
2010-08-10 15:21:28 +04:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has both heads:
$ hg -R ua heads
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 15:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ hg -R ua parents --template "{node|short}\n"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ rm -r ua
Testing clone -u <branch>:
$ hg clone -u stable a ua
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to branch default
tests: unify test-clone
2010-08-10 15:21:28 +04:00
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Repo ua has both heads:
$ hg -R ua heads
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 15:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 15:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 15:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
$ rm -r ua
tests: unify test-clone
2010-08-10 15:21:28 +04:00
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
Testing #<bookmark>:
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ hg clone -u . a#stable ua
adding changesets
adding manifests
adding file changes
added 14 changesets with 14 changes to 3 files
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
new changesets acb14030fe0a:7b0a8591eda2
updating to branch default
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 13:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
Same revision checked out in repo a and ua:
$ hg -R a parents --template "{node|short}\n"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ hg -R ua parents --template "{node|short}\n"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ 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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
new changesets acb14030fe0a:7b0a8591eda2
updating to branch default
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 13:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
Same revision checked out in repo a and ua:
$ hg -R a parents --template "{node|short}\n"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ hg -R ua parents --template "{node|short}\n"
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7bc8ee83a26f
tests: unify test-clone
2010-08-10 15:21:28 +04:00
$ 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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
new changesets acb14030fe0a:7b0a8591eda2
updating to branch default
tests: unify test-clone
2010-08-10 15:21:28 +04:00
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 13:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
Branch 'stable' is checked out:
$ hg -R ua parents
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 13:7b0a8591eda2
bookmark: stable
tests: unify test-clone
2010-08-10 15:21:28 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: another change for branch stable
$ rm -r ua
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
@ 15:7b0a8591eda2
stable 15:7b0a8591eda2
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
$ hg clone . ../i
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to bookmark @
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
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id -i ../i
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
7b0a8591eda2
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
$ hg bookmark head1
$ hg -q up -r 0
$ echo head2 > foo
$ hg commit -m head2
$ hg bookmark head2
$ hg -q up -r 0
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
$ hg bookmark branch1
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
$ echo branch1 > foo
$ hg commit -m branch1
$ hg -q up -r 0
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
$ hg bookmark branch2
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
$ 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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
$TESTTMP/share/b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1/.hg
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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
$TESTTMP/source1a
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)
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
adding remote bookmark branch1
adding remote bookmark branch2
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
adding remote bookmark head1
adding remote bookmark head2
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
new changesets 4a8dc1ab4c13:79168763a548
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
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
$TESTTMP/share/b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1/.hg
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
branch1 5:ec6257d0246c
branch2 6:79168763a548
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
head1 3:4a8dc1ab4c13
head2 4:99f71071f117
Default path should be source, not share.
$ hg -R share-dest1b config paths.default
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
$TESTTMP/source1b
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 .
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
changeset: 6:79168763a548
bookmark: branch2
tag: tip
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
parent: 0:b5f04eac9d8f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
summary: branch2
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
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)
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
new changesets b5f04eac9d8f:79168763a548
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
adding remote bookmark branch1
adding remote bookmark branch2
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
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
-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".
lock: suggest running debugprocesstree to figure out what's blocking Summary: This would help people unblock themselves. Reviewed By: markbt Differential Revision: D9443602 fbshipit-source-id: f05e2b2390a88a9280149d2164c2d7ab71c29600
2018-08-23 07:26:50 +03:00
$ (grep 'new pooled' race1.log > /dev/null && cat race1.log || cat race2.log) | egrep -v '(lock|debugprocess)'
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
lock: suggest running debugprocesstree to figure out what's blocking Summary: This would help people unblock themselves. Reviewed By: markbt Differential Revision: D9443602 fbshipit-source-id: f05e2b2390a88a9280149d2164c2d7ab71c29600
2018-08-23 07:26:50 +03:00
$ (grep 'existing pooled' race1.log > /dev/null && cat race1.log || cat race2.log) | egrep -v '(lock|debugprocess)'
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to bookmark @
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
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to bookmark @
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
(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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to bookmark @
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
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to bookmark @
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
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to bookmark @
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
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
test-clone: stop using or testing named branches Summary: Make it future proof. Differential Revision: D14030469 fbshipit-source-id: 84369a7870bcb5703194f2e8cc140b54ce6de458
2019-02-13 08:39:24 +03:00
updating to bookmark @
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
(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