summaryrefslogtreecommitdiff
path: root/t/t4102-apply-rename.sh
diff options
context:
space:
mode:
authorLibravatar Jonathan Nieder <jrnieder@gmail.com>2012-10-05 00:04:31 -0700
committerLibravatar Eric Wong <normalperson@yhbt.net>2012-10-05 22:52:52 +0000
commitdc01f880a53e56d4a5c6f30cb2d7b9412e17bfe7 (patch)
treedfccdd185c81f5db8ce400c364460b5fe1100bbf /t/t4102-apply-rename.sh
parentGit::SVN: rename private path field (diff)
downloadtgif-dc01f880a53e56d4a5c6f30cb2d7b9412e17bfe7.tar.xz
git-svn: keep leading slash when canonicalizing paths (fallback case)
Subversion's svn_dirent_canonicalize() and svn_path_canonicalize() APIs keep a leading slash in the return value if one was present on the argument, which can be useful since it allows relative and absolute paths to be distinguished. When git-svn's canonicalize_path() learned to use these functions if available, its semantics changed in the corresponding way. Some new callers rely on the leading slash --- for example, if the slash is stripped out then _canonicalize_url_ourselves() will transform "proto://host/path/to/resource" to "proto://hostpath/to/resource". Unfortunately the fallback _canonicalize_path_ourselves(), used when the appropriate SVN APIs are not usable, still follows the old semantics, so if that code path is exercised then it breaks. Fix it to follow the new convention. Noticed by forcing the fallback on and running tests. Without this patch, t9101.4 fails: Bad URL passed to RA layer: Unable to open an ra_local session to \ URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\ t9101-git-svn-props/svnrepo' contains unsupported hostname at \ /home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148 With it, the git-svn tests pass again. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
Diffstat (limited to 't/t4102-apply-rename.sh')
0 files changed, 0 insertions, 0 deletions