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

RE: line-ending conversion and keyword substitution

From: Sander Striker <striker_at_apache.org>
Date: 2001-12-13 01:34:36 CET

> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: 13 December 2001 01:14

> On Wed, 2001-12-12 at 17:43, Bruce Atherton wrote:
>> In that case, I guess I should submit a proposal of what I understood your
>> proposal to be, since I think it has the benefits of Greg's system without
>> requiring the flip-flopping of line endings in the repository.

The flip-flopping is something to consider. Like Greg Stein pointed
out on irc: what if you use another tool to browse the repos (cadaver,
web folders). The diff between versions could become quite large then.

> I wouldn't be too disappointed at your proposal being implemented, but I
> think I'm still fond of mine because:
>
> 1. It's simpler.
> 2. Its integrity guarantees (such as they are) are rock-solid.
>
> To illustrate 2, I'll go back to my little vector graphic example.
> Let's say I'm on Windows, and we're using your newline proposal. I
> create my no-vectors graphic file, save it, and check it in. Let's say
> the initial contents are "VEC\n", which would be a little odd,
> especially for a Windows program, but this is a binary format; it could
                                                  ^^^^^^

svn defaults to binary (so no conversion) unless told otherwise right?
I can therefor only see this problem in the case where you use import
to get a number of files into the repos, having a heuristic to figure
out what kind of files they are (and the heuristic screwing up becuase
your vector file resembles a normal text file).

> be anything. Then, next week, I check out the file. Even though it
> came from Windows, my client transforms the file contents to "VEC\r\n",
> because it has no idea where the file came from; it just thinks it looks
> like a Unix text file. I load the file in my vector graphics program

My personal opinion would be that anything that is first checked in on
windows, marked for addition as text file, should default to CRLF line
ending style. On a unix client it should default to LF line ending style.
I think this is least likely to cause surprises.

People that need something different than the default, will simply need
to set the line ending style by hand. (with a gui it would ofcourse
just be: select files... properties -> line endings -> [x] CRLF [ ] LF.
Boy would a gui be nice ;^).

> and, because this is my example, the program is forgiving enough not to
> lose due to that particular LF -> CRLF translation, and still sees the
> file as empty.
>
> Now I create my complex engine design, save the file, and commit it.
> Because the client transformed LF to CRLF, on commit it decides it needs
> to transform CRLF to LF, destroying the engine design.

/me doesn't like the engine design being destroyed, but I don't think
there is a win-win situation here.

Sander

---------------------------------------------------------------------
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:52 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.