On Thu, 9 Dec 2004, Eric Hanchrow wrote:
> Here's what I did:
>
> $ svn switch http://svn.collab.net/repos/svn/tags/1.1.1
> U Makefile.in
> U build.conf
> ...
>
> 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.
That's true... here's my guess as to what's happening: because the
eol-style is 'native', on commit, Subversion will convert the end-of-line
markers to its internal preferred (Unix) format - so the version that gets
committed will be identical to the one already in the repository.
> 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.
It's true that the script won't work in your WC when you've just
unix2dos-ed it, and it would be nice to know that - but on the other hand,
at least there's no risk of committing a change that will break other
people...
Patrick
--
The easy way to type accents in Windows: http://www.frkeys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 10 03:43:24 2004