Fresh checkout shows modified files

2013-10-11 Thread Stümpfig , Thomas
Hi all, for some directories I get modified working copies right after a fresh checkout. This seems very strange to me. I do not get any error message. My Platform is Windows 7 64 Bit. I am using TortoiseSVN 1.8.1, Build 24570 - 64 Bit as client. Visual SVN as server. But also tortoise svn

Re: Fresh checkout shows modified files

2013-10-11 Thread Stefan Sperling
On Fri, Oct 11, 2013 at 09:41:33AM +, Stümpfig, Thomas wrote: Hi all, for some directories I get modified working copies right after a fresh checkout. This seems very strange to me. I do not get any error message. My Platform is Windows 7 64 Bit. I am using TortoiseSVN 1.8.1, Build

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread T.J. Perovich
On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just

RE: SVN Blame Returns Corrupt Data

2013-10-11 Thread Bob Archer
On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Branko Čibej
On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to

RE: SVN Blame Returns Corrupt Data

2013-10-11 Thread Bob Archer
On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Branko Čibej
On 11.10.2013 16:55, Bob Archer wrote: On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit

RE: SVN Blame Returns Corrupt Data

2013-10-11 Thread Bob Archer
On 11.10.2013 16:55, Bob Archer wrote: On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Branko Čibej
On 11.10.2013 17:19, Bob Archer wrote: On 11.10.2013 16:55, Bob Archer wrote: On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to

RE: SVN Blame Returns Corrupt Data

2013-10-11 Thread Bob Archer
On 11.10.2013 17:19, Bob Archer wrote: On 11.10.2013 16:55, Bob Archer wrote: On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Branko Čibej
On 11.10.2013 18:12, Bob Archer wrote: On 11.10.2013 17:19, Bob Archer wrote: On 11.10.2013 16:55, Bob Archer wrote: On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Andreas Krey
On Fri, 11 Oct 2013 17:43:30 +, Branko ??ibej wrote: ... Of course, if someone used the U+2424 newline code point instead, then in the worst case, the whole file would be interpreted as a single line. And SVN would be right, as U+2424 is 'SYMBOL FOR NEWLINE', which is actually a printable

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Ben Reser
On 10/11/13 9:22 AM, Branko Čibej wrote: You'd have to extend Subversion's file type detection to detect UTF-16. See svn_io_detect_mimetype2 in line in this file: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/io.c?view=markup Subversion currently only looks at the

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Stefan Sperling
On Fri, Oct 11, 2013 at 09:52:31AM -0700, Ben Reser wrote: On 10/11/13 9:22 AM, Branko Čibej wrote: You'd have to extend Subversion's file type detection to detect UTF-16. See svn_io_detect_mimetype2 in line in this file:

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Branko Čibej
On 11.10.2013 18:52, Ben Reser wrote: On 10/11/13 9:22 AM, Branko Čibej wrote: You'd have to extend Subversion's file type detection to detect UTF-16. See svn_io_detect_mimetype2 in line in this file: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/io.c?view=markup

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Branko Čibej
On 11.10.2013 19:25, Stefan Sperling wrote: On Fri, Oct 11, 2013 at 09:52:31AM -0700, Ben Reser wrote: On 10/11/13 9:22 AM, Branko Čibej wrote: You'd have to extend Subversion's file type detection to detect UTF-16. See svn_io_detect_mimetype2 in line in this file:

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Branko Čibej
On 11.10.2013 18:23, Andreas Krey wrote: On Fri, 11 Oct 2013 17:43:30 +, Branko ??ibej wrote: ... Of course, if someone used the U+2424 newline code point instead, then in the worst case, the whole file would be interpreted as a single line. And SVN would be right, as U+2424 is 'SYMBOL

Re: SVN Blame Returns Corrupt Data

2013-10-11 Thread Ben Reser
On 10/11/13 10:25 AM, Stefan Sperling wrote: Couldn't Subversion automatically convert UTF-16 files to UTF-8 before processing them for diff/merge/blame, and convert output written to the original files back to UTF-16? That's what the patch I pointed out did. Nobody seemed to object to the