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

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

kfogel writes:

    Eric Hanchrow <of...@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.

-- 
[Dijkstra's] great strength is that he is uncompromising.  It
would make him physically ill to think of programming in C++.
        -- Donald E. Knuth

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

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

[kf...@collab.net]

"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > 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.
>
> I think the current behaviour is logical. I think it is changes to the
> "normalized" file that counts. Same for modifications inside an expanded
> keyword, I think.

I think I agree.

Subversion does the right thing if you don't set the 'svn:eol-style'
property.  But if you *do* set it, that's tantamount to asking
Subversion to behave specially in certain operations.  Commit is one
of those operations, but (as we see) so is status.


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

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

["Peter N. Lundblad" <pe...@famlundblad.se>]

On Mon, 13 Dec 2004 kfogel@collab.net wrote:

> Eric Hanchrow <of...@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.
>
I think the current behaviour is logical. I think it is changes to the
"normalized" file that counts. Same for modifications inside an expanded
keyword, I think.

Regards,
//Peter

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

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

[kf...@collab.net]

Eric Hanchrow <of...@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