You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2001/11/08 17:38:03 UTC
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
You guys (Kevin and Branko) want to have this newline conversion
discussion on the list, instead of in the issues database?
Just askin'. :-)
-K
issues@subversion.tigris.org writes:
> http://subversion.tigris.org/issues/show_bug.cgi?id=524
>
> *** shadow/issues_15/524 Wed Nov 7 15:20:09 2001
> --- shadow/issues_15/524.tmp.4094 Thu Nov 8 06:03:31 2001
> ***************
> *** 65,67 ****
> --- 65,85 ----
> If a text file has a specific newline-style (e.g., "dos"), then that's
> what you store in the repository. End of problem.
>
> +
> +
> + ------- Additional Comments From kevin@tigris.org 2001-11-08 06:03 -------
> + The justification for this is as follows:
> +
> + Consider a shop that is primarily windows, but with a unix svn server.
> + We would like to be able to specify that the default format for files
> + in the repository is windows, so that clients don't have to spend the
> + time doing translation all the time. Then files that HAVE to be dos
> + would be marked dos, and files that HAVE to be unix would be unix etc.
> +
> + This allows the client to be more efficient, by not always translating
> + to the format of the server.
> +
> + This allows lets any unix clients no that the repository files will
> + be in dos format, and that THEY would have to do the conversion.
> +
> + Clearer now?
> \ No newline at end of file
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: issues-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: issues-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Thu, 8 Nov 2001, Kevin Pilch-Bisson wrote:
>
>>>>>+ This allows the client to be more efficient, by not always translating
>>>>>+ to the format of the server.
>>>>>
>
>This way lies madness. The overhead of clients doing newline translation
>is vanishingly small compared to the overhead of us writing code and
>creating bugs.
>
>Don't optimize too soon, and optimize for order-of-magnitude gains before
>optimizing for small constant or linear-factor gains.
>
Thanks, Greg, you said this better than I could. Sometimes I have
trouble articulating what I mean.
--
Brane �ibej <br...@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
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
Posted by Greg Hudson <gh...@mit.edu>.
On Thu, 8 Nov 2001, Kevin Pilch-Bisson wrote:
> > >>+ This allows the client to be more efficient, by not always translating
> > >>+ to the format of the server.
This way lies madness. The overhead of clients doing newline translation
is vanishingly small compared to the overhead of us writing code and
creating bugs.
Don't optimize too soon, and optimize for order-of-magnitude gains before
optimizing for small constant or linear-factor gains.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Nov 08, 2001 at 07:00:39PM +0100, Branko ?ibej wrote:
> >>+ Consider a shop that is primarily windows, but with a unix svn server.
> >>+ We would like to be able to specify that the default format for files
> >>+ in the repository is windows, so that clients don't have to spend the
> >>+ time doing translation all the time. Then files that HAVE to be dos
> >>+ would be marked dos, and files that HAVE to be unix would be unix etc.
> >>+
> >>+ This allows the client to be more efficient, by not always translating
> >>+ to the format of the server.
> >>+
> >>+ This allows lets any unix clients no that the repository files will
> >>+ be in dos format, and that THEY would have to do the conversion.
> >>+
> >>+ Clearer now?
> >>
>
> 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.
>
Another use case: Say you have a shop which maintains multiple products
some for windows some for unix. They may want to have the windows products
dirs default to windows line-endings, and the unix ones default to unix
line-endings.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
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 <br...@xbc.nu> writes:
> Karl Fogel wrote:
>
> >Branko Čibej <br...@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 <br...@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
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Branko �ibej <br...@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 <br...@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
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@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.
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.
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.
Why does the repository have to know anything about newline styles?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 524] Changed - line-ending conversion and keyword expansion
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>You guys (Kevin and Branko) want to have this newline conversion
>discussion on the list, instead of in the issues database?
>
>Just askin'. :-)
>
Heh. Here goes:
>>+ ------- Additional Comments From kevin@tigris.org 2001-11-08 06:03 -------
>>+ The justification for this is as follows:
>>+
>>+ Consider a shop that is primarily windows, but with a unix svn server.
>>+ We would like to be able to specify that the default format for files
>>+ in the repository is windows, so that clients don't have to spend the
>>+ time doing translation all the time. Then files that HAVE to be dos
>>+ would be marked dos, and files that HAVE to be unix would be unix etc.
>>+
>>+ This allows the client to be more efficient, by not always translating
>>+ to the format of the server.
>>+
>>+ This allows lets any unix clients no that the repository files will
>>+ be in dos format, and that THEY would have to do the conversion.
>>+
>>+ Clearer now?
>>
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.
--
Brane �ibej <br...@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