Oh.
Brane, we're in agreement then. It's fine to have a "default" newline
format which is assumed for text files (how the file is determined to
be text is another, independent matter -- we decided to always assume
binary, and let properties on files and/or parent dirs override that),
and clients can just assume that the default newline style holds for
text files when not told otherwise. Sure, let's save the property
storage space, by all means.
I got confused because this default was being referred to as the
"native repository format", as though the repository has something to
do with any of this. It doesn't. This is a set of conventions agreed
on by clients; the repository would have no code related to this.
-K
Branko Čibej <brane@xbc.nu> writes:
> 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
---------------------------------------------------------------------
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