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.
Hmmm. I'm not sure whether this should count as a bug or not.
On the one hand, the working file is certainly modified.
On the other hand, if you run 'svn commit', nothing would happen. The
file isn't modified as far as Subversion is concerned, because it has
a property indicating that certain kinds of line-ending changes can be
(effectively) ignored.
Does "M" mean "modified at all" or "modified in Subversion's universe"?
I don't believe we've thought hard on this question yet. Want to take
this thread to the dev@ list? I think you can dispense with the usual
lead in, just summarize the problem and give the recipe I quoted
above.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 13 20:48:34 2004