You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by James McCoy <ja...@debian.org> on 2014/01/04 16:20:12 UTC
"svn diff -r N file" in 1.7.14 is broken if svn:mime-type is present
Given the repository svn://scm.gforge.inria.fr/svn/mpfr/misc/vl-tests:
$ svn co $repo
A vl-tests2/mpfrtests.data
A vl-tests2/mpfrtests.sh
A vl-tests2/release-3.1.2-p4
A vl-tests2/release-3.1.0-p8
A vl-tests2/vfy-data
A vl-tests2/ReadMe
Checked out revision 8727.
$ cd vl-tests
$ svn diff -r 8276 ReadMe
Index: ReadMe
===================================================================
Cannot display: file marked as a binary type.
svn: E000022: Valid UTF-8 data
(hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28 48 67)
followed by invalid UTF-8 sequence
(hex: fb 20 0a 7f)
The actual values reported vary among runs of "svn diff", sometimes
writing garbage characters to the terminal. It appears to only occur
with files that have the svn:mime-type property set.
This works correctly with 1.7.13 and 1.8.5.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <ja...@debian.org>
Re: "svn diff -r N file" in 1.7.14 is broken if svn:mime-type is
present
Posted by Ben Reser <be...@reser.org>.
On 1/24/14, 8:55 AM, Ben Reser wrote:
> That's my intention. I have a fix I just need to get the tests written. I
> wanted to add the tests first to trunk and in the process of writing the tests
> I found more problems with diff that impact trunk and 1.8. It's like turtles
> all the way down. :)
Nominated for backport to 1.7.x in r1563083 and should be included in 1.7.15.
If you don't want to wait for 1.7.15 you can get a diff that will apply against
1.7.14 with:
REPO=https://svn.apache.org/repos/asf/subversion/branches
svn diff $REPO/1.7.x $REPO/1.7.x-issue4460
Thanks for your bug report, we botched diff quite a bit in 1.7.14.
Re: "svn diff -r N file" in 1.7.14 is broken if svn:mime-type is
present
Posted by Ben Reser <be...@reser.org>.
On 1/24/14, 7:52 AM, James McCoy wrote:
>
> On Jan 4, 2014 5:10 PM, "Ben Reser" <ben@reser.org <ma...@reser.org>> wrote:
>> What's really going on here for anyone that cares about the details is the
>> major rework of diff code we added for issues #4153 and #4421 incorrectly
>> assumes that the value of the property in the property hash is a C string when
>> in fact it is a svn_string_t.
>>
>> I should have a fix here soon.
>
> Is this going to make it into the upcoming 1.7.15 release?
That's my intention. I have a fix I just need to get the tests written. I
wanted to add the tests first to trunk and in the process of writing the tests
I found more problems with diff that impact trunk and 1.8. It's like turtles
all the way down. :)
My plan is to try and finish this up today.
Re: "svn diff -r N file" in 1.7.14 is broken if svn:mime-type is present
Posted by James McCoy <ja...@debian.org>.
On Jan 4, 2014 5:10 PM, "Ben Reser" <be...@reser.org> wrote:
> What's really going on here for anyone that cares about the details is the
> major rework of diff code we added for issues #4153 and #4421 incorrectly
> assumes that the value of the property in the property hash is a C string
when
> in fact it is a svn_string_t.
>
> I should have a fix here soon.
Is this going to make it into the upcoming 1.7.15 release?
Cheers,
James
Re: "svn diff -r N file" in 1.7.14 is broken if svn:mime-type is
present
Posted by Ben Reser <be...@reser.org>.
On 1/4/14, 7:20 AM, James McCoy wrote:
> Given the repository svn://scm.gforge.inria.fr/svn/mpfr/misc/vl-tests:
>
> $ svn co $repo
> A vl-tests2/mpfrtests.data
> A vl-tests2/mpfrtests.sh
> A vl-tests2/release-3.1.2-p4
> A vl-tests2/release-3.1.0-p8
> A vl-tests2/vfy-data
> A vl-tests2/ReadMe
> Checked out revision 8727.
> $ cd vl-tests
> $ svn diff -r 8276 ReadMe
> Index: ReadMe
> ===================================================================
> Cannot display: file marked as a binary type.
> svn: E000022: Valid UTF-8 data
> (hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28 48 67)
> followed by invalid UTF-8 sequence
> (hex: fb 20 0a 7f)
>
>
> The actual values reported vary among runs of "svn diff", sometimes
> writing garbage characters to the terminal. It appears to only occur
> with files that have the svn:mime-type property set.
>
> This works correctly with 1.7.13 and 1.8.5.
I've reproduced this on OS X, so it's not Debian specific. This is a client
side implementation bug, there is no corruption in the repo.
The client is incorrectly calculating the mime-type (it ends up being garbage).
Since the mime-type doesn't match a text type it's treated as a binary type,
which triggers an error. The error tries to print out the mime-type which
since it's garbage isn't valid UTF-8 data, thus all the hex output.
Users can somewhat workaround this in 1.7.14 by using --force (which will
bypass the mime-type error). However it'll show a spurious property difference
that isn't really there (which seems to be a different bug).
What's really going on here for anyone that cares about the details is the
major rework of diff code we added for issues #4153 and #4421 incorrectly
assumes that the value of the property in the property hash is a C string when
in fact it is a svn_string_t.
I should have a fix here soon.