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

line ending summary: the "Breg Hudtherton Proposal"

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2001-12-13 20:09:38 CET

Whew, that is one heck of a thread. :-) I'm really glad we had the
discussion, though; all the current proposals are improvements on what
we started with.

The two contenders appear to be Greg Hudson's and Bruce Atherton's
proposals. They actually have a lot in common, so below I'm going to
describe them as one proposal with a "variation" step, and our
remaining decision is which way to go in that variation.

Note that I have simplified them slightly, to reduce the number of
properties, but haven't changed anything fundamental (I think).

Here we go:

   The Breg Hudtherton Proposal:

   1. The property `svn:convert-line-endings' means convert line
      endings to client native form.

      For example, when this property is on, a LF file in a Windows
      working copy would be LF in the repository, LF in text-base, and
      CRLF in the working file. All client operations compensate as
      necessary, including patch and diff; these are implementation
      details. The point is that the default state (the state of
      files when an svn operation is not going on) is as described

      In the same working copy, a CRLF file would be CRLF everywhere.
      The "conversion" is a no-op, because the file is already in
      local style.

      (Note: don't care about the actual prop name and exact values,
      those are implementation details.)

      This property is unset by default.

   2. There is no other property :-). In particular, no property says
      what style the file has in the repository. It has whatever
      style it was created with. If the client is doing newline
      conversion at all, it does it based on what it sees in the file,
      it doesn't need to be told what's in the file. If the file
      appears to have mixed newline styles, we can either fold them
      all to one way, or do no conversion. IMHO either way is
      acceptable in such a case, see below.

   3. This is the variation step:

      3a - The exact bits of the working file are always sent to the
           repository on commit, and the repository (and text-base)
           updated accordingly. This means that alternating commits
           from different platforms would flip-flop the line-ending
           style in the HEAD; on the other hand, it guarantees that
           EOL conversion will never change the data someone thought
           they committed.


      3b - The newline style of text-base is preserved, and the bits
           converted as they're committed. After the commit, the
           repository and text-base are in the same style they were
           before, and the working file is in the same style *it*
           was in before.

           If text-base appears to have mixed newlines, then
           probably we should just commit exactly whatever was in
           the working file (i.e., effectively making that the new
           canonical form of the file in the repository).

Both variations require the modified-p test, etc, to be tweaked.

I currently lean mildly toward 3a, because of the safety guarantee,
and because the consequences of flip-flop in the repository are not so
bad. (See `Appendix A' below for why I claim this. :-) ).

Votes? A simple "+1 3a" or "+1 3b" will suffice, although if you have
more to say, feel free.


Appendix A: Why do I claim flip-flop is not so bad?

Think of all the ways you can access the repository. If you're
browsing it with a web browser, it can handle any newline style it
sees. If you're accessing it with a Subversion client, you'll get the
proper newline conversion anyway, so no problem there.

Only if you're accessing it with some other DAV client, well, then
yes, you'll get whatever random newline style was last stored, but
consider: if you can't handle that style, then there was a 50% chance
that you wouldn't have been able to handle the file anyway (because if
there were a reliable repository-wide style, there's no guarantee it
would have been suitable for your particular client platform anyway!).

In other words, there's always *someone* who will have to do newline
conversion, we can't avoid that. If a client isn't able to do that,
than some of the files in the repository are just going to be
problematic. We can't solve that.

And of course, for files for which there is only one appropriate
newline style, they will always have that style in the repository
(because Subversion clients will never change their style, because the
property won't be set), so they'll be okay whoever checks them out.
If you retrieve them with some dav client that doesn't honor the
property, and your platform's editor messes up the newlines, and you
commit, well, I don't see how any scheme can prevent that.

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

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