summaryrefslogtreecommitdiff
path: root/perl/Git/SVN/Utils.pm
AgeCommit message (Collapse)AuthorFilesLines
2020-10-21perl: check for perl warnings while running testsLibravatar Jeff King1-1/+1
We set "use warnings" in most of our perl code to catch problems. But as the name implies, warnings just emit a message to stderr and don't otherwise affect the program. So our tests are quite likely to miss that warnings are being spewed, as most of them do not look at stderr. We could ask perl to make all warnings fatal, but this is likely annoying for non-developers, who would rather have a running program with a warning than something that refuses to work at all. So instead, let's teach the perl code to respect an environment variable (GIT_PERL_FATAL_WARNINGS) to increase the severity of the warnings. This can be set for day-to-day running if people want to be really pedantic, but the primary use is to trigger it within the test suite. We could also trigger that for every test run, but likewise even the tests failing may be annoying to distro builders, etc (just as -Werror would be for compiling C code). So we'll tie it to a special test-mode variable (GIT_TEST_PERL_FATAL_WARNINGS) that can be set in the environment or as a Makefile knob, and we'll automatically turn the knob when DEVELOPER=1 is set. That should give developers and CI the more careful view without disrupting normal users or packagers. Note that the mapping from the GIT_TEST_* form to the GIT_* form in test-lib.sh is necessary even if they had the same name: the perl scripts need it to be normalized to a perl truth value, and we also have to make sure it's exported (we might have gotten it from the environment, but we might also have gotten it from GIT-BUILD-OPTIONS directly). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-17git svn: do not overescape URLs (fallback case)Libravatar Jonathan Nieder1-1/+1
Subversion's canonical URLs are intended to make URL comparison easy and therefore have strict rules about what characters are special enough to urlencode and what characters should be left alone. When in the fallback codepath because unable to use libsvn's own canonicalization function for some reason, escape special characters in URIs according to the svn_uri__char_validity[] table in subversion/libsvn_subr/path.c (r935829). The libsvn versions that trigger this code path are not likely to be strict enough to care, but it's nicer to be consistent. Noticed by using SVN 1.6.17 perl bindings, which do not provide SVN::_Core::svn_uri_canonicalize (triggering the fallback code), with libsvn 1.7.5, whose do_switch is fussy enough to care: Committing to file:///home/jrn/src/git/t/trash%20directory.\ t9118-git-svn-funky-branch-names/svnrepo/pr%20ject/branches\ /more%20fun%20plugin%21 ... svn: E235000: In file '[...]/subversion/libsvn_subr/dirent_uri.c' \ line 2291: assertion failed (svn_uri_is_canonical(url, pool)) error: git-svn died of signal 6 not ok - 3 test dcommit to funky branch After this change, the '!' in 'more%20fun%20plugin!' is not urlencoded and t9118 passes again. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn: keep leading slash when canonicalizing paths (fallback case)Libravatar Jonathan Nieder1-1/+0
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>
2012-08-02git-svn: introduce add_path_to_url functionLibravatar Michael G. Schwern1-0/+27
Remove the ad-hoc versions. This is mostly to normalize the process and ensure the URLs produced don't have double slashes or anything. Also provides a place to fix the corner case where a file path contains a percent sign. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: attempt to mimic SVN 1.7 URL canonicalizationLibravatar Michael G. Schwern1-2/+17
Previously, our URL canonicalization didn't do much of anything. Now it actually escapes and collapses slashes. This is mostly a cut & paste of escape_url from git-svn. This is closer to how SVN 1.7's canonicalization behaves. Doing it with 1.6 lets us chase down some problems caused by more effective canonicalization without having to deal with all the other 1.7 issues on top of that. * Remote URLs have to be canonicalized otherwise Git::SVN->find_existing_remote will think they're different. * The SVN remote is now written to the git config canonicalized. That should be ok. Adjust a test to account for that. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: path canonicalization uses SVN APILibravatar Michael G. Schwern1-0/+24
All tests pass with SVN 1.6. SVN 1.7 remains broken, not worrying about it yet. SVN changed its path canonicalization API between 1.6 and 1.7. http://svnbook.red-bean.com/en/1.6/svn.developer.usingapi.html#svn.developer.usingapi.urlpath http://svnbook.red-bean.com/en/1.7/svn.developer.usingapi.html#svn.developer.usingapi.urlpath The SVN API does not accept foo/.. but it also doesn't canonicalize it. We have to do it ourselves. [ew: commit title, fall back if SVN <= 1.6 fails to canonicalize] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02Git::SVN::Utils: remove irrelevant commentLibravatar Michael G. Schwern1-2/+0
The code doesn't use File::Spec. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: add join_paths() to safely concatenate pathsLibravatar Michael G. Schwern1-0/+32
Otherwise you might wind up with things like... my $path1 = undef; my $path2 = 'foo'; my $path = $path1 . '/' . $path2; creating '/foo'. Or this... my $path1 = 'foo/'; my $path2 = 'bar'; my $path = $path1 . '/' . $path2; creating 'foo//bar'. Could have used File::Spec, but I'm shying away from it due to SVN 1.7's pickiness about paths. Felt it would be better to have our own we can control completely. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: factor out _collapse_dotdot functionLibravatar Michael G. Schwern1-1/+13
The SVN API functions will not accept ../foo but their canonicalization functions will not collapse it. So we'll have to do it ourselves. _collapse_dotdot() works better than the existing regex did. This will be used shortly when canonicalize_path() starts using the SVN API. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: use SVN 1.7 to canonicalize when possibleLibravatar Michael G. Schwern1-0/+16
No change on SVN 1.6. The tests all pass with SVN 1.6 if canonicalize_url() does nothing, so tests passing doesn't have much meaning. The tests are so messed up right now with SVN 1.7 it isn't really useful to check. They will be useful later. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: move canonicalization to Git::SVN::UtilsLibravatar Michael G. Schwern1-1/+51
So they can be used by others. I'd like to test them, but they're going to become SVN API wrappers shortly and those aren't predictable. No functional change. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-07-27Extract some utilities from git-svn to allow extracting Git::SVN.Libravatar Michael G. Schwern1-0/+59
Put them in a new module called Git::SVN::Utils. Yeah, not terribly original and it will be a dumping ground. But its better than having them in the main git-svn program. At least they can be documented and tested. * fatal() is used by many classes. * Change the $can_compress lexical into a function. This should be enough to extract Git::SVN. Signed-off-by: Michael G. Schwern <schwern@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>