[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Should "svn st" report line-ending changes on files whose svn:eol-style property is set?

From: <kfogel_at_collab.net>
Date: 2004-12-13 22:47:22 CET

Eric Hanchrow <offby1@blarg.net> writes:
> Find a text file whose svn:eol-style is native.
>
> $ file BUGS
> BUGS: ASCII English text
> $ svn pg svn:eol-style BUGS
> native
>
> Edit the file by adding carriage-returns to the ends of the lines.
> $ unix2dos BUGS
> $ file BUGS
> BUGS: ASCII English text, with CRLF line terminators
>
> Ask subversion if this file has changed.
> $ svn st BUGS
> $
>
> Hmm. Subversion says this file hasn't been edited, but of course it
> has. This seems bugaceous (that's a word because I say it is :-); I
> would have expected ``svn st BUGS'' to have yielded
>
> M BUGS
>
> Here's why it would be good to know that the file has been edited: if
> the file in question were a Perl script instead of a text file, then
> accidentally running ``unix2dos'' on it will break it (because the
> kernel will look for an executable named /usr/bin/perl^M), and it
> would be nice to be alerted to such breakage.

So, thoughts folks? :-)

I'm loathe to report a file as 'M'odified, if Subversion's not going
to commit it when you type 'svn ci'. On the other hand, the working
file *is* modified.

In case it's not clear what's going on here:

The reason Subversion doesn't think the file is modified modified is
that when SVN "translates" the working file back into canonical form,
for comparison with the text base, the file loses its funky line
endings, and so becomes identical to the text base.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 13 22:50:31 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.