Re: eol style differences

brane@xbc.nu writes:

> > Using working copy style might be better most of the time (I'm not
> > really convinced but I'll just assume it is for now), but it's not
> > clear to me that it is always better. Two problems come to mind.
> > First, suppose one is comparing two different revisions, using '-rX'
> > or '-rX:Y', then there will be two svn:eol-styles and they may not be
> > the same. Does each revision of the file get translated according to
> > it's own svn:eol-style, or does one svn:eol-style get used for both?
>
> I'd propose two things: a) always use the svn:eol-style that's on the version
> your'e looking at;

  $ svn st -v foo.c
         5 5 philip foo.c
  $ svn diff -r3:4 foo.c

Which is "the version you're looking at", 3, 4 or 5?

Now consider the case without a working copy

  $ svn diff -r3:4 http://server/repo/foo.c

3 or 4?

Now consider merge

  $ svn merge -r3:4 foo.c foo.c

3, 4 or 5?

> and b) remove all keytword expansions when doing diffs. Our internal
> diff lib can do that on-the-fly; for an external diff, we have to
> munge the WC file, too. Sigh.
>
> > The second problem is more to do with how svn:eol-style works in
> > general. It is possible to have a repository format file with CRLF
> > line-endings and svn:eol-style set to native.
>
> That's not how svn:eol-style works; that's how svn:eol-style
> *does't* work. It's a bug, right?

I agree svn:eol-style doesn't work :) I would describe the current
behaviour as "haphazard".

> Oh. What if you change svn:eol-style on a URL? Wheee...

The client doesn't let you use propset on an URL, not yet anyway.

That is the basic problem though, svn:eol-style is enforced in the
client (by libsvn_wc I think) and so not all clients will do it. I
think the following is a likely failure mode: a file has svn:eol-style
set to native and a generic WebDAV client on Windows is used to commit
a version of the file with CRLF endings.

> > On Windows a repository
> > format comparison should show every line changed, a working copy
> > comparison should show no change. Which is correct?
>
> Actually, if you convert the pristine copy, you'll see no change on Unix, too.
> Which is bad, because then you'll commit the "no change" and be delightfully
> surprised at having changed every line ending in the repo. Oh, duh.

So we just drop svn:eol-style as a mistake? It's not just Subversion,
the last time I used ClearCase on a Windows/Unix project we stopped
using ClearCase's eol conversion, it didn't do the right thing as far
as we were concerned.

Assuming that dropping svn:eol-style is not going to happen, I wonder
what we can do? Perhaps we should disable the conversion if the
text-base is not "correct", and provide a way for the user to force
the file to be "repaired". It gets a bit tricky when one already has
a translated working copy and an 'svn up' brings in a new text-base
that has faulty eols.

The problem is that simply defining what eol-conversion should do is
hard, when one gets beyond the very basic cases anyway. I don't think
anyone knows how it should behave, so we certainly don't know how to
implement it. My last question about the behaviour didn't get a
response

http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=31827

> > Perhaps the solution is that whichever format we choose to use for
> > diff, a command line flag should be available to cause the other
> > format to be used.
>
> I agree, that flag is useful for other things, too (e.g., svn cat)

Indeed, in issue 399 I suggested a '--raw' option to disable eol
conversion.

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