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

Re: [Issue 524] Changed - line-ending conversion and keyword expansion

From: Branko Čibej <brane_at_xbc.nu>
Date: 2001-11-08 22:42:17 CET

Karl Fogel wrote:

>Branko �ibej <brane@xbc.nu> writes:
>>I guessed it would be something like that. However, that doesn't
>>change my position: the native newline separator is a property of the
>>whole repository. I really don't see why one should be able to change
>>this per file, or per directory.
>I don't understand why the repository has to have a "native newline
>separator" at all.
Because "native" text files have to be stored in the repository in some
known format that the clients know about.

>If newline conversion is done entirely on the client side, then it
>doesn't matter how the repository stores a file -- it can just store
>it however it was checked in. Doesn't matter if that's LF, CRLF, or
>LFCR. The *file* itself (or its parent directory, whatever) should
>indicate what kind of file it is.
Exactly, and the default for text files is "svn:newline-style=native".

>Here's how the client deals with this:
> - If the file (or parent dir, whatever) has no properties
> indicating that any particular sort of newline conversion should
> happen, then it just gets checked out as-is.
> - If props indicate that platform-specific conversion should be
> done, and that this file is a "text" file of type "xxx" (where
> "xxx" indicates its newline style), then all xxx newlines in the
> file get converted to client-local newlines, and the reverse
> conversion happens on the way back to the server.
This means that a) you have to have two newline-related props on a file,
or b) the client must check directory props to know what to do with text
files. Just the parent props, or recurse all the way to the top? Or do
subdirectories inherit this particular prop from their parents?

This looks like too much magic to me, sorry. Imagine this scenario:

    * File A is a "native" text file, checked in on Windows, so it's
      stored with \r\n.
    * Check out A on Unix (\r\n->\n), modify and check in -- the repo
      stores \n.
    * Check out on Mac (\n->\r), modify and check in -- the repo stores \r.
    * ...

This is too horrible to imagine.

>Why does the repository have to know anything about newline styles?
It doesn't, but the client must.

The more I think about it, the more it seems that this issue is totally
bogus. I mean, the newline conversion that the client has to do is
insignificant, if you take into account that it has to compute vdeltas,
etc. If this is done correctly, you don't even have to make another pass
over the file -- you can do the newline conversion on the fly while
generating or parsing the text delta, and nobody will notice the
difference in performance.

(For instance: CVS always stores files with \n, and converts to and from
\r\n on Windows. I don't think anybody has noticed the slowdown this
extra work causes ...)

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 Sat Oct 21 14:36:48 2006

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