You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Chapman <dc...@acm.org> on 2011/02/01 21:39:29 UTC
missing carriage returns from output of "svn diff" in Windows
Running Subversion 1.6.15 under Windows 7, if I redirect the output of
"svn diff" to a file and then try to edit that file using Notepad, the
line breaks are garbled. In particular they have only the '\n'
character, not the '\r' character.
For example, if "svn_usage_notes.txt" is in my repository, and I do the
following in a sandbox:
echo foo >> svn_usage_notes.txt
echo bar >> svn_usage_notes.txt
echo zot >> svn_usage_notes.txt
svn diff svn_usage_notes.txt > wowow.txt
od -c wowow.txt
I get:
0000000 I n d e x : s v n _ u s a g e
0000020 _ n o t e s . t x t \r \n = = = =
0000040 = = = = = = = = = = = = = = = =
*
0000120 = = = = = = = = = = = = = = = \r
0000140 \n - - - s v n _ u s a g e _ n
0000160 o t e s . t x t \t ( r e v i s i
0000200 o n 1 1 1 6 ) \r \n + + + s v
0000220 n _ u s a g e _ n o t e s . t x
0000240 t \t ( w o r k i n g c o p y )
0000260 \r \n @ @ - 6 1 2 2 , 3 + 6 1
0000300 2 2 , 6 @ @ \r \n \n M a r k
0000320 P h i p p a r d \n h t t p :
0000340 / / m a r k p h i p . b l o g s
0000360 p o t . c o m / \n + f o o \n +
0000400 b a r \n + z o t \n
0000413
Note how the first part of the file has "\r\n" while the last part
(showing the extra lines) has only '\n'. The file itself has "\r\n" for
every line, and I have the following line in
C:\Users\David\AppData\Roaming\Subversion\config:
*.txt = svn:eol-style=native
The absence of newlines makes it impossible to view the differences file
in Notepad. Years ago before I knew about "unzip -a", I wrote a program
to add carriage returns to text files being copied from Linux to Windows
and so I can use that, but it would be nice to have system-appropriate
line endings in the output of "svn diff" without this extra step.
Is anyone else seeing this? Is there a configuration parameter I can
set to fix it, or is it a bug that should be bumped to the dev list?
(For the record, I have "UnxUtils.zip" loaded, so I have a number of
Unix/Linux utilities such as "od" available under Windows, and only the
Windows Subversion executable ever writes into a Windows sandbox.)
Thanks.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: missing carriage returns from output of "svn diff" in Windows
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 01, 2011 at 12:39:29PM -0800, David Chapman wrote:
> 0000000 I n d e x : s v n _ u s a g e
> 0000020 _ n o t e s . t x t \r \n = = = =
> 0000040 = = = = = = = = = = = = = = = =
> *
> 0000120 = = = = = = = = = = = = = = = \r
> 0000140 \n - - - s v n _ u s a g e _ n
> 0000160 o t e s . t x t \t ( r e v i s i
> 0000200 o n 1 1 1 6 ) \r \n + + + s v
> 0000220 n _ u s a g e _ n o t e s . t x
> 0000240 t \t ( w o r k i n g c o p y )
> 0000260 \r \n @ @ - 6 1 2 2 , 3 + 6 1
> 0000300 2 2 , 6 @ @ \r \n \n M a r k
> 0000320 P h i p p a r d \n h t t p :
> 0000340 / / m a r k p h i p . b l o g s
> 0000360 p o t . c o m / \n + f o o \n +
> 0000400 b a r \n + z o t \n
> 0000413
>
> Note how the first part of the file has "\r\n" while the last part
> (showing the extra lines) has only '\n'. The file itself has "\r\n"
> for every line, and I have the following line in
> C:\Users\David\AppData\Roaming\Subversion\config:
>
> *.txt = svn:eol-style=native
This is a known issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=3338
Stefan
Re: missing carriage returns from output of "svn diff" in Windows
Posted by David Chapman <dc...@acm.org>.
On 2/1/2011 1:29 PM, Johan Corveleyn wrote:
> On Tue, Feb 1, 2011 at 9:39 PM, David Chapman<dc...@acm.org> wrote:
>> Running Subversion 1.6.15 under Windows 7, if I redirect the output of "svn
>> diff" to a file and then try to edit that file using Notepad, the line
>> breaks are garbled. In particular they have only the '\n' character, not
>> the '\r' character.
>>
>> For example, if "svn_usage_notes.txt" is in my repository, and I do the
>> following in a sandbox:
>>
>> echo foo>> svn_usage_notes.txt
>> echo bar>> svn_usage_notes.txt
>> echo zot>> svn_usage_notes.txt
>> svn diff svn_usage_notes.txt> wowow.txt
>> od -c wowow.txt
>>
>> I get:
>>
>> 0000000 I n d e x : s v n _ u s a g e
>> 0000020 _ n o t e s . t x t \r \n = = = =
>> 0000040 = = = = = = = = = = = = = = = =
>> *
>> 0000120 = = = = = = = = = = = = = = = \r
>> 0000140 \n - - - s v n _ u s a g e _ n
>> 0000160 o t e s . t x t \t ( r e v i s i
>> 0000200 o n 1 1 1 6 ) \r \n + + + s v
>> 0000220 n _ u s a g e _ n o t e s . t x
>> 0000240 t \t ( w o r k i n g c o p y )
>> 0000260 \r \n @ @ - 6 1 2 2 , 3 + 6 1
>> 0000300 2 2 , 6 @ @ \r \n \n M a r k
>> 0000320 P h i p p a r d \n h t t p :
>> 0000340 / / m a r k p h i p . b l o g s
>> 0000360 p o t . c o m / \n + f o o \n +
>> 0000400 b a r \n + z o t \n
>> 0000413
>>
>> Note how the first part of the file has "\r\n" while the last part (showing
>> the extra lines) has only '\n'. The file itself has "\r\n" for every line,
>> and I have the following line in
>> C:\Users\David\AppData\Roaming\Subversion\config:
>>
>> *.txt = svn:eol-style=native
> Ok, that may be your client side config, but maybe it's not working
> correctly or not being picked up for whatever reason. Can you verify
> directly whether the property is set on the file?
>
> svn propget svn:eol-style svn_usage_notes.txt
"svn propget svn:eol-style svn_usage_notes.txt" returns "native", as
expected. I should point out that the problem is not specific to this
one file, but is common to every text file in my sandboxes (including C
and C++ source code). I've been using Subversion for years under both
Windows and Linux and am pretty careful to set autoprops for all
appropriate file types. Bad things happen otherwise...
>> The absence of newlines makes it impossible to view the differences file in
>> Notepad. Years ago before I knew about "unzip -a", I wrote a program to add
>> carriage returns to text files being copied from Linux to Windows and so I
>> can use that, but it would be nice to have system-appropriate line endings
>> in the output of "svn diff" without this extra step.
>>
>> Is anyone else seeing this? Is there a configuration parameter I can set to
>> fix it, or is it a bug that should be bumped to the dev list?
> Certainly no need to escalate to the dev list (unless we're going to
> discuss design/implementation considerations or something). We can
> discuss it on this list, and if we find out it's a genuine issue, you
> can submit it to the issue tracker.
It's been a while since I was subscribed to this list, and as I recall
bumping to dev was the next step. Submitting an issue works for me if
that's the preferred way now.
>> (For the record, I have "UnxUtils.zip" loaded, so I have a number of
>> Unix/Linux utilities such as "od" available under Windows, and only the
>> Windows Subversion executable ever writes into a Windows sandbox.)
> Ok, this may be a very important detail. Can you first try to
> reproduce this issue without the UnxUtils loaded?
Uninstalling the Unix utility set is rather a drastic step, but I
removed its executable directory from the
search path for a newly opened shell (there is no "od" and no "diff" on
the search path; I checked). Same result.
> Which client are you using actually (which distribution)? You aren't
> using one from cygwin are you? There are known problems with the svn
> client that comes with cygwin (don't know the details, but I think it
> can be confused about its native eol-style, because it thinks it's
> running on unix etc.).
>
> Also, is this something new you're seeing only from 1.6.15? Can you
> try reproducing with an older version, and try to find out when the
> problem first appeared?
The installation is Windows native (i.e. Command Prompt) from
Setup-Subversion-1.6.15.msi, downloaded December 26, 2010 as I was
building a new machine to recover from a crash on my old one. :-( I've
never used Cygwin; I always try to ensure that I have enough machines
that I can boot Linux in native mode on a separate machine alongside my
Windows machine. TortoiseSVN is not installed either.
My eight-year-old ThinkPad wheezes a bit, but it still boots Windows XP
eventually and is running Subversion 1.4.5 from svn-win32-1.4.5.zip
(don't know where I got it, but the download file is dated December
2007). Even with the UnxUtils executable directory removed from the
laptop shell's search path, I get the same result. It too is a "bare"
Subversion installation operating from the Command Prompt without Cygwin
or TortoiseSVN. So this has been going on for a while.
The server, BTW, is running Subversion 1.6.11 under Slackware 13.1.
This is the build that came with the distro; I didn't see a need to
upgrade (though I could if there is a compelling reason). Not that I
think server-side is the cause...
Thanks for your comments.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: missing carriage returns from output of "svn diff" in Windows
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 1, 2011 at 9:39 PM, David Chapman <dc...@acm.org> wrote:
> Running Subversion 1.6.15 under Windows 7, if I redirect the output of "svn
> diff" to a file and then try to edit that file using Notepad, the line
> breaks are garbled. In particular they have only the '\n' character, not
> the '\r' character.
>
> For example, if "svn_usage_notes.txt" is in my repository, and I do the
> following in a sandbox:
>
> echo foo >> svn_usage_notes.txt
> echo bar >> svn_usage_notes.txt
> echo zot >> svn_usage_notes.txt
> svn diff svn_usage_notes.txt > wowow.txt
> od -c wowow.txt
>
> I get:
>
> 0000000 I n d e x : s v n _ u s a g e
> 0000020 _ n o t e s . t x t \r \n = = = =
> 0000040 = = = = = = = = = = = = = = = =
> *
> 0000120 = = = = = = = = = = = = = = = \r
> 0000140 \n - - - s v n _ u s a g e _ n
> 0000160 o t e s . t x t \t ( r e v i s i
> 0000200 o n 1 1 1 6 ) \r \n + + + s v
> 0000220 n _ u s a g e _ n o t e s . t x
> 0000240 t \t ( w o r k i n g c o p y )
> 0000260 \r \n @ @ - 6 1 2 2 , 3 + 6 1
> 0000300 2 2 , 6 @ @ \r \n \n M a r k
> 0000320 P h i p p a r d \n h t t p :
> 0000340 / / m a r k p h i p . b l o g s
> 0000360 p o t . c o m / \n + f o o \n +
> 0000400 b a r \n + z o t \n
> 0000413
>
> Note how the first part of the file has "\r\n" while the last part (showing
> the extra lines) has only '\n'. The file itself has "\r\n" for every line,
> and I have the following line in
> C:\Users\David\AppData\Roaming\Subversion\config:
>
> *.txt = svn:eol-style=native
Ok, that may be your client side config, but maybe it's not working
correctly or not being picked up for whatever reason. Can you verify
directly whether the property is set on the file?
svn propget svn:eol-style svn_usage_notes.txt
> The absence of newlines makes it impossible to view the differences file in
> Notepad. Years ago before I knew about "unzip -a", I wrote a program to add
> carriage returns to text files being copied from Linux to Windows and so I
> can use that, but it would be nice to have system-appropriate line endings
> in the output of "svn diff" without this extra step.
>
> Is anyone else seeing this? Is there a configuration parameter I can set to
> fix it, or is it a bug that should be bumped to the dev list?
Certainly no need to escalate to the dev list (unless we're going to
discuss design/implementation considerations or something). We can
discuss it on this list, and if we find out it's a genuine issue, you
can submit it to the issue tracker.
> (For the record, I have "UnxUtils.zip" loaded, so I have a number of
> Unix/Linux utilities such as "od" available under Windows, and only the
> Windows Subversion executable ever writes into a Windows sandbox.)
Ok, this may be a very important detail. Can you first try to
reproduce this issue without the UnxUtils loaded?
Which client are you using actually (which distribution)? You aren't
using one from cygwin are you? There are known problems with the svn
client that comes with cygwin (don't know the details, but I think it
can be confused about its native eol-style, because it thinks it's
running on unix etc.).
Also, is this something new you're seeing only from 1.6.15? Can you
try reproducing with an older version, and try to find out when the
problem first appeared?
Cheers,
--
Johan