facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-09 00:14:35 +03:00
Code Issues Projects Releases Wiki Activity
5b83a79f69
sapling/tests/test-default-push.t

148 lines
3.5 KiB
Perl
Raw Normal View History

tests: unify test-default-push
2010-09-15 00:54:04 +04:00
$ hg init a
$ echo a > a/a
$ hg --cwd a ci -Ama
adding a
$ hg clone a c
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg clone a b
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo b >> b/a
$ hg --cwd b ci -mb
push: provide a hint when no paths in configured (issue3692) When user type "hg push" command then this patch helps user by providing hint if no default path is configured. Second patch is the test coverage, to test the change behaviour of first patch.
2014-02-25 02:41:11 +04:00
Push should provide a hint when both 'default' and 'default-push' not set:
$ cd c
$ hg push --config paths.default=
abort: default repository not configured!
push: update help hint to point to config.paths section
2016-09-20 23:12:38 +03:00
(see 'hg help config.paths')
push: provide a hint when no paths in configured (issue3692) When user type "hg push" command then this patch helps user by providing hint if no default path is configured. Second patch is the test coverage, to test the change behaviour of first patch.
2014-02-25 02:41:11 +04:00
[255]
$ cd ..
tests: unify test-default-push
2010-09-15 00:54:04 +04:00
Push should push to 'default' when 'default-push' not set:
$ hg --cwd b push
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
pushing to $TESTTMP/a (glob)
tests: unify test-default-push
2010-09-15 00:54:04 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
Push should push to 'default-push' when set:
config: use the same hgrc for a cloned repo as for an uninitted repo This just copies the same local sample hgrc, except it sets the default path to the repo it was cloned from. This is cut-and-paste from the local sample hgrc, but I think it's acceptable, since the two pieces of code are right next to each other and they're small. There is danger of them going out of synch, but it would complicate the code too much to get rid of this C&P. I also add ui as an import to hg.py, but with demandimport, this should not be a noticeable performance hit.
2014-10-07 00:35:02 +04:00
$ echo '[paths]' >> b/.hg/hgrc
tests: unify test-default-push
2010-09-15 00:54:04 +04:00
$ echo 'default-push = ../c' >> b/.hg/hgrc
$ hg --cwd b push
tests: make (glob) on windows accept \ instead of / Globbing is usually used for filenames, so on windows it is reasonable and very convenient that glob patterns accepts '\' or '/' when the pattern specifies '/'.
2011-11-07 06:25:10 +04:00
pushing to $TESTTMP/c (glob)
tests: unify test-default-push
2010-09-15 00:54:04 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
ui: change default path fallback mechanism (issue4796) The previous paths API code always fell back to the default path. This was wrong because if a requested path doesn't exist, that should error. Only if no path was requested should we fall back to the default. As part of implementing the test case for issue 4796, it was discovered that the "repository does not exist" error message raised by localrepository.__init__ wasn't being seen because the paths API validates paths before localrepository.__init__ was being called. The exception and error message from localrepository.__init__ has been introduced to getpath(). This necessitated rewriting expandpath() both to catch the exception and to have proper default fallback. This code is more complicated than I'd like. But making all tests pass was a big chore. As more code moves to getpath(), there will likely be opportunities to improve things a bit.
2015-09-06 21:28:48 +03:00
push: restore old behavior of default-push (issue5000) This effectively backs out 163c899d1e46 and f44b0edaab90. We can't handle "default-push" just like "default:pushurl" because it is a stand-alone named path. Instead, I have two ideas to work around the issue: a. two defaults: getpath(dest, default=('default-push', 'default')) b. virtual path: getpath(dest, default=':default') (a) is conservative approach and will have less trouble, but callers have to specify they need "default-push" or "default". (b) generates hidden ":default" path from "default" and "default-push", and callers request ":default". This will require some tricks and won't work if there are conflicting sub-options valid for both "pull" and "push". I'll take (a) for default branch. This patch should NOT BE MERGED to default except for tests because it would break handling of "pushurl" sub-option.
2015-12-26 09:18:16 +03:00
But push should push to 'default' if explicitly specified (issue5000):
$ hg --cwd b push default
pushing to $TESTTMP/a (glob)
searching for changes
no changes found
[1]
ui: support paths.default-push without paths.default set (issue4914) This behavior regressed as part of the paths API refactoring. Previous behavior was to accept "default-push" without "default" defined. Current behavior aborts with "default repository not configured!." This patch restores the old behavior and adds test coverage for the scenario, which was absent before.
2015-10-22 21:59:03 +03:00
Push should push to 'default-push' when 'default' is not set
$ hg -q clone a push-default-only
$ cd push-default-only
$ rm .hg/hgrc
$ touch foo
$ hg -q commit -A -m 'add foo'
$ hg --config paths.default-push=../a push
pushing to $TESTTMP/a (glob)
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
$ cd ..
ui: change default path fallback mechanism (issue4796) The previous paths API code always fell back to the default path. This was wrong because if a requested path doesn't exist, that should error. Only if no path was requested should we fall back to the default. As part of implementing the test case for issue 4796, it was discovered that the "repository does not exist" error message raised by localrepository.__init__ wasn't being seen because the paths API validates paths before localrepository.__init__ was being called. The exception and error message from localrepository.__init__ has been introduced to getpath(). This necessitated rewriting expandpath() both to catch the exception and to have proper default fallback. This code is more complicated than I'd like. But making all tests pass was a big chore. As more code moves to getpath(), there will likely be opportunities to improve things a bit.
2015-09-06 21:28:48 +03:00
Pushing to a path that isn't defined should not fall back to default
$ hg --cwd b push doesnotexist
abort: repository doesnotexist does not exist!
[255]
ui: support declaring path push urls as sub-options Power users often want to apply per-path configuration options. For example, they may want to declare an alternate URL for push operations or declare a revset of revisions to push when `hg push` is used (as opposed to attempting to push all revisions by default). This patch establishes the use of sub-options (config options with ":" in the name) to declare additional behavior for paths. New sub-options are declared by using the new ``@ui.pathsuboption`` decorator. This decorator serves multiple purposes: * Declaring which sub-options are registered * Declaring how a sub-option maps to an attribute on ``path`` instances (this is needed to `hg paths` can render sub-options and values properly) * Validation and normalization of config options to attribute values * Allows extensions to declare new sub-options without monkeypatching * Allows extensions to overwrite built-in behavior for sub-option handling As convenient as the new option registration decorator is, extensions (and even core functionality) may still need an additional hook point to perform finalization of path instances. For example, they may wish to validate that multiple options/attributes aren't conflicting with each other. This hook point could be added later, if needed. To prove this new functionality works, we implement the "pushurl" path sub-option. This option declares the URL that `hg push` should use by default. We require that "pushurl" is an actual URL. This requirement might be controversial and could be dropped if there is opposition. However, objectors should read the complicated code in ui.path.__init__ and commands.push for resolving non-URL values before making a judgement. We also don't allow #fragment in the URLs. I intend to introduce a ":pushrev" (or similar) option to define a revset to control which revisions are pushed when "-r <rev>" isn't passed into `hg push`. This is much more powerful than #fragment and I don't think #fragment is useful enough to continue supporting. The [paths] section of the "config" help page has been updated significantly. `hg paths` has been taught to display path sub-options. The docs mention that "default-push" is now deprecated. However, there are several references to it that need to be cleaned up. A large part of this is converting more consumers to the new paths API. This will happen naturally as more path sub-options are added and more and more components need to access them.
2015-12-06 08:11:04 +03:00
:pushurl is used when defined
$ hg -q clone a pushurlsource
$ hg -q clone a pushurldest
$ cd pushurlsource
tests: make `pwd` URL compatible on Windows in test-default-push Without this, the test fails with: $ hg -q commit -A -m 'add pushurl' abort: file:// URLs can only refer to localhost $ hg push abort: file:// URLs can only refer to localhost The variable $PWD causes check-code to complain, so avoid that.
2015-12-17 01:17:36 +03:00
Windows needs a leading slash to make a URL that passes all of the checks
$ WD=`pwd`
#if windows
$ WD="/$WD"
#endif
ui: support declaring path push urls as sub-options Power users often want to apply per-path configuration options. For example, they may want to declare an alternate URL for push operations or declare a revset of revisions to push when `hg push` is used (as opposed to attempting to push all revisions by default). This patch establishes the use of sub-options (config options with ":" in the name) to declare additional behavior for paths. New sub-options are declared by using the new ``@ui.pathsuboption`` decorator. This decorator serves multiple purposes: * Declaring which sub-options are registered * Declaring how a sub-option maps to an attribute on ``path`` instances (this is needed to `hg paths` can render sub-options and values properly) * Validation and normalization of config options to attribute values * Allows extensions to declare new sub-options without monkeypatching * Allows extensions to overwrite built-in behavior for sub-option handling As convenient as the new option registration decorator is, extensions (and even core functionality) may still need an additional hook point to perform finalization of path instances. For example, they may wish to validate that multiple options/attributes aren't conflicting with each other. This hook point could be added later, if needed. To prove this new functionality works, we implement the "pushurl" path sub-option. This option declares the URL that `hg push` should use by default. We require that "pushurl" is an actual URL. This requirement might be controversial and could be dropped if there is opposition. However, objectors should read the complicated code in ui.path.__init__ and commands.push for resolving non-URL values before making a judgement. We also don't allow #fragment in the URLs. I intend to introduce a ":pushrev" (or similar) option to define a revset to control which revisions are pushed when "-r <rev>" isn't passed into `hg push`. This is much more powerful than #fragment and I don't think #fragment is useful enough to continue supporting. The [paths] section of the "config" help page has been updated significantly. `hg paths` has been taught to display path sub-options. The docs mention that "default-push" is now deprecated. However, there are several references to it that need to be cleaned up. A large part of this is converting more consumers to the new paths API. This will happen naturally as more path sub-options are added and more and more components need to access them.
2015-12-06 08:11:04 +03:00
$ cat > .hg/hgrc << EOF
> [paths]
> default = https://example.com/not/relevant
tests: make `pwd` URL compatible on Windows in test-default-push Without this, the test fails with: $ hg -q commit -A -m 'add pushurl' abort: file:// URLs can only refer to localhost $ hg push abort: file:// URLs can only refer to localhost The variable $PWD causes check-code to complain, so avoid that.
2015-12-17 01:17:36 +03:00
> default:pushurl = file://$WD/../pushurldest
ui: support declaring path push urls as sub-options Power users often want to apply per-path configuration options. For example, they may want to declare an alternate URL for push operations or declare a revset of revisions to push when `hg push` is used (as opposed to attempting to push all revisions by default). This patch establishes the use of sub-options (config options with ":" in the name) to declare additional behavior for paths. New sub-options are declared by using the new ``@ui.pathsuboption`` decorator. This decorator serves multiple purposes: * Declaring which sub-options are registered * Declaring how a sub-option maps to an attribute on ``path`` instances (this is needed to `hg paths` can render sub-options and values properly) * Validation and normalization of config options to attribute values * Allows extensions to declare new sub-options without monkeypatching * Allows extensions to overwrite built-in behavior for sub-option handling As convenient as the new option registration decorator is, extensions (and even core functionality) may still need an additional hook point to perform finalization of path instances. For example, they may wish to validate that multiple options/attributes aren't conflicting with each other. This hook point could be added later, if needed. To prove this new functionality works, we implement the "pushurl" path sub-option. This option declares the URL that `hg push` should use by default. We require that "pushurl" is an actual URL. This requirement might be controversial and could be dropped if there is opposition. However, objectors should read the complicated code in ui.path.__init__ and commands.push for resolving non-URL values before making a judgement. We also don't allow #fragment in the URLs. I intend to introduce a ":pushrev" (or similar) option to define a revset to control which revisions are pushed when "-r <rev>" isn't passed into `hg push`. This is much more powerful than #fragment and I don't think #fragment is useful enough to continue supporting. The [paths] section of the "config" help page has been updated significantly. `hg paths` has been taught to display path sub-options. The docs mention that "default-push" is now deprecated. However, there are several references to it that need to be cleaned up. A large part of this is converting more consumers to the new paths API. This will happen naturally as more path sub-options are added and more and more components need to access them.
2015-12-06 08:11:04 +03:00
> EOF
$ touch pushurl
$ hg -q commit -A -m 'add pushurl'
$ hg push
pushing to file:/*/$TESTTMP/pushurlsource/../pushurldest (glob)
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
ui: path option to declare which revisions to push by default Now that we have a mechanism for declaring path sub-options, we can start to pile on features! Many power users have expressed frustration that bare `hg push` attempts to push all local revisions to the remote. This patch introduces the "pushrev" path sub-option to control which revisions are pushed when no "-r" argument is specified. The value of this sub-option is a revset, naturally. A future feature addition could potentially introduce a "pushnames" sub-options that declares the list of names (branches, bookmarks, topics, etc) to push by default. The entire "what to push by default" feature should probably be considered before this patch lands.
2016-06-26 17:59:02 +03:00
:pushrev is used when no -r is passed
$ cat >> .hg/hgrc << EOF
> default:pushrev = .
> EOF
$ hg -q up -r 0
$ echo head1 > foo
$ hg -q commit -A -m head1
$ hg -q up -r 0
$ echo head2 > foo
$ hg -q commit -A -m head2
$ hg push -f
pushing to file:/*/$TESTTMP/pushurlsource/../pushurldest (glob)
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
$ hg --config 'paths.default:pushrev=draft()' push -f
pushing to file:/*/$TESTTMP/pushurlsource/../pushurldest (glob)
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
Invalid :pushrev raises appropriately
$ hg --config 'paths.default:pushrev=notdefined()' push
pushing to file:/*/$TESTTMP/pushurlsource/../pushurldest (glob)
hg: parse error: unknown identifier: notdefined
[255]
$ hg --config 'paths.default:pushrev=(' push
pushing to file:/*/$TESTTMP/pushurlsource/../pushurldest (glob)
hg: parse error at 1: not a prefix: end
[255]
ui: support declaring path push urls as sub-options Power users often want to apply per-path configuration options. For example, they may want to declare an alternate URL for push operations or declare a revset of revisions to push when `hg push` is used (as opposed to attempting to push all revisions by default). This patch establishes the use of sub-options (config options with ":" in the name) to declare additional behavior for paths. New sub-options are declared by using the new ``@ui.pathsuboption`` decorator. This decorator serves multiple purposes: * Declaring which sub-options are registered * Declaring how a sub-option maps to an attribute on ``path`` instances (this is needed to `hg paths` can render sub-options and values properly) * Validation and normalization of config options to attribute values * Allows extensions to declare new sub-options without monkeypatching * Allows extensions to overwrite built-in behavior for sub-option handling As convenient as the new option registration decorator is, extensions (and even core functionality) may still need an additional hook point to perform finalization of path instances. For example, they may wish to validate that multiple options/attributes aren't conflicting with each other. This hook point could be added later, if needed. To prove this new functionality works, we implement the "pushurl" path sub-option. This option declares the URL that `hg push` should use by default. We require that "pushurl" is an actual URL. This requirement might be controversial and could be dropped if there is opposition. However, objectors should read the complicated code in ui.path.__init__ and commands.push for resolving non-URL values before making a judgement. We also don't allow #fragment in the URLs. I intend to introduce a ":pushrev" (or similar) option to define a revset to control which revisions are pushed when "-r <rev>" isn't passed into `hg push`. This is much more powerful than #fragment and I don't think #fragment is useful enough to continue supporting. The [paths] section of the "config" help page has been updated significantly. `hg paths` has been taught to display path sub-options. The docs mention that "default-push" is now deprecated. However, there are several references to it that need to be cleaned up. A large part of this is converting more consumers to the new paths API. This will happen naturally as more path sub-options are added and more and more components need to access them.
2015-12-06 08:11:04 +03:00
$ cd ..
Reference in New Issue Copy Permalink