sapling/eden/scm/tests/test-schemes.t
Mark Juggurnauth-Thomas 0ec7d7de75 make it possible to access Mononoke repos with slashes in their names
Summary:
Mononoke repo names are permitted to contain slashes, however currently Sapling's URL parsing doesn't understand this, and instead has a bunch of hacks designed to work around misunderstandings of URIs.  As a result, Sapling can't currently clone them.

You can look at resources like [Wikipedia's artical on URIs](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) if you are not familiar with how uniform resource identifier syntax should work.

We fix this by handling the `mononoke` and `fb` URI schemes specifically.

* For the `mononoke` scheme, the authority is the Mononoke server and the path is the name of the repository, with any leading or trailing slashes removed.

* For the `fb` scheme, the path is the name of the repository, and there should be no authority as the server is implicit.   This means a valid `fb` scheme URI is of the form `fb:reponame`.  Unfortunately, since people misunderstand `://` to be a single token, existing `fb` URIs exist of the form `fb://reponame`.  This is a problem, as if the repo name has a slash in it, it becomes `fb://firstpart/secondpart`, where `firstpart` is the authority and `secondpart` is the path.  We handle this specially by taking the scheme-specific part as a whole and removing all leading and trailing slashes.

In order to fix the second in the long-term, we must also fix up how the `schemes` extension handles URIs like the `fb` scheme.  In a similar vein, we substitute the full scheme-specific part in the target URL.  This will allow us to migrate from `fb://reponame` to `fb:reponame`, at which point we can use correct URI parsing in the `fb` scheme, as we do for the `mononoke` scheme.

Reviewed By: yancouto

Differential Revision: D41771964

fbshipit-source-id: e93060afe316f4b965a6d1770b1b88a8d60e5f5c
2022-12-08 06:43:09 -08:00

83 lines
2.2 KiB
Perl

#chg-compatible
#debugruntest-compatible
#inprocess-hg-incompatible
$ setconfig experimental.allowfilepeer=True
$ enable infinitepush remotefilelog remotenames schemes treemanifest
$ . "$TESTDIR/library.sh"
$ mkcommit() {
> echo "$1" > "$1"
> hg add "$1"
> hg ci -m "$1"
> }
$ newserver server
$ cd ..
$ newremoterepo client1
$ cat >> .hg/hgrc << EOF
> [paths]
> default = dotdot://server
> default-push = push:server
> normal-path = mononoke://mononoke.internal.tfbnw.net/server
> [remotefilelog]
> fallbackpath = fallback://server
> [schemes]
> dotdot = ssh://user@dummy/{1}
> fallback = ssh://user@dummy/{1}
> fb-test = mononoke://mononoke.internal.tfbnw.net/{1}
> i = ssh://user@dummy/{1}
> iw = ssh://user@dummy/{1}
> push = ssh://user@dummy/{1}
> z = file:\$PWD/
> EOF
$ setconfig infinitepush.branchpattern="re:scratch/.+"
test converting debug output for all paths
$ hg debugexpandpaths
paths.default=ssh://user@dummy/server (expanded from dotdot://server)
paths.default-push=ssh://user@dummy/server (expanded from push:server)
paths.normal-path=mononoke://mononoke.internal.tfbnw.net/server (not expanded)
check that paths are expanded
check that debugexpandscheme outputs the canonical form
$ hg debugexpandscheme fb-test:opsfiles
mononoke://mononoke.internal.tfbnw.net/opsfiles
check this still works if someone adds some extra slashes
$ hg debugexpandscheme fb-test://opsfiles
mononoke://mononoke.internal.tfbnw.net/opsfiles
expanding an unknown scheme emits the input
$ hg debugexpandscheme foobar://this/that
foobar://this/that
$ mkcommit foobar
$ hg push --create --to master
pushing rev 582ab9cb184e to destination push:server bookmark master
searching for changes
exporting bookmark master
remote: adding changesets
remote: adding manifests
remote: adding file changes
$ mkcommit something
$ hg push -r . --to scratch/test123 --create
pushing to push:server
searching for changes
remote: pushing 1 commit:
remote: 6e16a5f9c216 something
$ hg pull -r 6e16a5f9c216
pulling from dotdot://server/
no changes found
adding changesets
adding manifests
adding file changes