Philip Martin wrote:
>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?
>
3 and 4; that's what it says, -r3:4
>Now consider the case without a working copy
>
> $ svn diff -r3:4 http://server/repo/foo.c
>
>3 or 4?
>
Again, both 3 and 4
>Now consider merge
>
> $ svn merge -r3:4 foo.c foo.c
>
>3, 4 or 5?
>
All three.
>>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".
>
My point exactly. .-)
>>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.
>
Ah, right. A gleam of hope there.
>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.
>
Well, we really can't do anything about that. Except if we started
converting eol style on the server, which nightmare I shy away in horror
from.
>>>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.
>
I really don't know. The intent of svn:eol-style was to get coherent
results (diffs, that is) when people use all those editors out there
that can't preserve the eol style.
>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.
>
I guess the first thing to do is tabulate how things can go wrong, what
we can fix automatically, and which cases we can catch with a warning or
failure. It's not easy, I know
>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
>
Ah, yes. Your question here probably covers about 5% of the cases. As I
said, we have to finally tabulate them all.
Any volunteers? This is a nice, self-contained task that only requires
somebody with a clear head and lots of patience; no Subversion knowlege
is required. :-)
>>>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.
>
>
Yes, that would make sense, too -- --eol-style=(native|CR|LF|CRLF|none)
would cover it, right?
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 12 20:27:16 2003