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

Re: svn diff / blame -x --ignore-space-change doesn't ignore EOL style changes

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 21 Apr 2011 07:07:31 +0300

On Wed, 20 Apr 2011 21:38 +0200, "Johan Corveleyn" <jcorvel_at_gmail.com> wrote:
> No, I don't think that's correct.
>
> --ignore-space-change: ignores changes in the amount of white-space,
> but not ignoring "all white-space". This means that "having no
> white-space" in not considered equal to "having white-space". Example:
> "abc def" is considered equal to "abc def", but not equal to
> "abcdef".
>
> --ignore-all-space: ignores all differences in white-space, including
> between "having no white-space" and "having white-space". I.e. "abc
> def" is considered equal to "abcdef".
>
> The above two only apply to white-space, not to eol-style, if I'm not
> mistaken.

Thanks for the correction, Johan. (I haven't tested your theory either, but I assumed you'd jump in if I were spreading misinformation about the diff code.)

> So the --ignore-eol-style is orthogonal.
>
> Can't you just use both options?
> svn diff / blame -x --ignore-space-change -x --ignore-eol-style
>
> Or, with the short option for ignoring space-change:
> svn diff / blame -x-b -x--ignore-eol-style
>

And here I thought the syntax would be

svn $subcommand -x "--ignore-space-change --ignore-eol-style"

though, of course, if your syntax works I'll use it from now on (because it's more easily parseable).

> (I generally prefer using --ignore-space-change instead of
> --ignore-all-space, because the latter can hide really important
> changes, which change the semantics e.g. in most programming languages
> or xml files and such).
>
> Cheers,
> --
> Johan
>
> On Wed, Apr 20, 2011 at 8:03 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > AIUI, --ignore-eol-style + --ignore-space-change == --ignore-all-space.  It seems to me that --ignore-all-space would work for your use case?
> >
> > On Wed, 20 Apr 2011 20:44 +0300, "Stanimir Stamenkov" <s7an10_at_netscape.net> wrote:
> >> The '--ignore-space-change' option, and '--ignore-all-space' for
> >> that matter, to the 'diff' and 'blame' commands doesn't seem to
> >> ignore changes in the EOL style.  I really expect each of:
> >>
> >> --ignore-eol-style
> >> --ignore-space-change
> >> --ignore-all-space
> >>
> >> in the given order to include the effect of the previous one.  There
> >> are many files which get initially created on Windows with CRLF
> >> line-endings, but without the 'svn:eol-style=native' property set.
> >> Then at some revision this property gets set and it gets very
> >> difficult track/find the origin of past changes, onwards.  The
> >> problem gets messier when the EOL style changes to LF and CRLF
> >> number of times before the 'svn:eol-style' gets properly set.
> >>
> >> Now, one could think:
> >>
> >> svn diff / blame -x --ignore-eol-style ...
> >>
> >> should be sufficient.  But then often I need to use:
> >>
> >> svn diff / blame -x --ignore-space-change ...
> >>
> >> to ignore any space changes, e.g. changes to "tabs vs. spaces-only"
> >> to the indentation (and elsewhere), which becomes impossible once
> >> the file has changed the EOL style number of times.
> >>
> >> Is the current behavior of the space ignoring options intended, or
> >> it appears omission?
> >>
> >> FWIW, I'm on Windows and I workaround the problem by having
> >> installed the 'diff' command from the GnuWin32 [1] packages, which
> >> doesn't seem to care about EOL style differences (treats them as equal):
> >>
> >> svn diff / blame --diff-cmd diff -x "--ignore-space-change ..." ...
> >>
> >> It would be really nice if the SVN default internal diff
> >> implementation adds the effect of '--ignore-eol-style' to the
> >> '--ignore-space-change' and '--ignore-all-space' options.
> >>
> >> [1] http://gnuwin32.sourceforge.net/
> >>
> >> --
> >> Stanimir
> >>
> >
>
Received on 2011-04-21 06:13:26 CEST

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

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