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
(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
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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:36:53 2006