Hi Eric,
Michael G Schwern wrote:
On 2012.7.28 6:50 AM, Jonathan Nieder wrote:
Michael G Schwern wrote:
--- a/perl/Git/SVN/Utils.pm
+++ b/perl/Git/SVN/Utils.pm
[...]
@@ -100,6 +102,20 @@ API as a URL.
=cut
sub canonicalize_url {
+ my $url = shift;
+
+ # The 1.7 way to do it
Hi,
Michael G. Schwern wrote:
--- a/perl/Git/SVN/Utils.pm
+++ b/perl/Git/SVN/Utils.pm
[...]
@@ -100,6 +102,20 @@ API as a URL.
=cut
sub canonicalize_url {
+ my $url = shift;
+
+ # The 1.7 way to do it
+ if ( defined SVN::_Core::svn_uri_canonicalize ) {
+
On 2012.7.28 6:50 AM, Jonathan Nieder wrote:
--- a/perl/Git/SVN/Utils.pm
+++ b/perl/Git/SVN/Utils.pm
[...]
@@ -100,6 +102,20 @@ API as a URL.
=cut
sub canonicalize_url {
+my $url = shift;
+
+# The 1.7 way to do it
+if ( defined SVN::_Core::svn_uri_canonicalize ) {
+
Michael G Schwern wrote:
On 2012.7.28 6:50 AM, Jonathan Nieder wrote:
If I am reading Subversion r873487 correctly, in ancient times,
svn_path_canonicalize() did the appropriate tweaking for URIs. Today
its implementation is comforting:
const char *
svn_path_canonicalize(const
On 2012.7.28 12:30 PM, Jonathan Nieder wrote:
I didn't know about that. I don't know what your SVN backwards compat
requirements are, but if that behavior goes back far enough in SVN to satisfy
you folks, then canonicalize_url() should fall back to
SVN::_Core::svn_path_canonicalize().
Jonathan Nieder wrote:
Michael G Schwern wrote:
I would suggest that worrying whether a few lines of code are introduced now
or 10 patches later in the same branch which is all going to be merged in one
go (and retesting the patches after it) is not the most important thing.
[...]
In that
On 2012.7.28 1:02 PM, Jonathan Nieder wrote:
Jonathan Nieder wrote:
Michael G Schwern wrote:
I would suggest that worrying whether a few lines of code are introduced now
or 10 patches later in the same branch which is all going to be merged in
one
go (and retesting the patches after it)
7 matches
Mail list logo