Bug? "svn st" doesn't report line-ending changes

[Eric Hanchrow <of...@blarg.net>]

This is with pristine svn 1.1.1 on Linux.  Built from checked-in
sources (as opposed to a released tarball); I configured by running
this "config.nice" with no arguments:

    "./configure" \
    "--cache-file=/usr/local/src/config.cache" \
    "--enable-shared" \
    "--prefix=/usr/local/stow/svn-1.1.x" \
    "-C" \
    "$@"

I use fsfs instead of berkeley DB, although I'm sure that's
irrelevant.

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.  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.

-- 
This movie doesn't scrape the bottom of the barrel.  This movie isn't
the bottom of the barrel.  This movie isn't below the bottom of the
barrel.  This movie doesn't deserve to be mentioned in the same
sentence with barrels.

        Roger Ebert on "Freddy Got Fingered"

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Bug? "svn st" doesn't report line-ending changes

[Patrick Smears <pa...@ensoft.co.uk>]

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