On Thu, Dec 13, 2001 at 01:09:38PM -0600, Karl Fogel wrote:
>...
> 1. The property `svn:convert-line-endings' means convert line
> endings to client native form.
Per other discussion on the list, I think people have said there should be a
way to enforce a particular CRLF, LF, or CR style (because the file is the
input to an inflexible tool).
>...
> 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.
I believe a warning for a mixed style file is desirable, overridable with
--force. More specifically, if the file is marked with a specific type
(CRLF, LF, CR) and it has newlines that don't match that style, then a
warning appears.
[ this is a tough choice though; it may be that somebody has inserted some
commentary or description or whatever into a file with an explicitly
different line style; but I'd say that line ending conversion should just
be disabled in such a case ]
>...
> 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
As discussed elsewhere, I think the flip-flop has big problems for us
because of our multiple access paths. CVS never had to deal with it because
it did not have an "official" mechanism for working with the repository
directly. Thus, they didn't have to "officially" support anything. We have a
mixed blessing here: we do have neato official access, but it also means
more support of more wonky things that people may do.
>...
> 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).
To be redundant... Warning. Force.
>...
> Votes? A simple "+1 3a" or "+1 3b" will suffice, although if you have
> more to say, feel free.
Not obvious yet? :-) +1 3b
>...
> 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.
By definition, HTTP User Agents are supposed to do this. Thankfully :-)
> If you're accessing it with a Subversion client, you'll get the
> proper newline conversion anyway, so no problem there.
Yup.
> Only if you're accessing it with some other DAV client, well, then
Or a program that binds to libsvn_fs ...
> 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!).
If you are considering a specific file at a specific point in time: yes, it
will "randomly" be correct for your platform or not.
BUT! If you look at a file across points in time, it will be right, then
wrong, then right, then wrong... Even worse, the apparent differences
between files fetched over a period of time will appear to be "the entire
file". The *actual* changes in the file will be completely obscured because
it looks like the whole darned file changed.
> 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.
True. But we can also provide some consistency over time to the files as
they reside in the repository.
> 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.
Per previous discussion, this is unworkable. I check out a CRLF file and
pull it into my text editor. My editor goes, "bleh. ugly file. let me just
fix this..." When that file goes back in, we should be ensuring the proper
newline format (IMO).
> 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.
Commit time is just a bit smarter about how to handle a specific newline
setting...
Cheers,
-g
--
Greg Stein, http://www.lyra.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:53 2006