(hit "reply" instead of "reply all", sorry)
Dale Worley wrote:
>> From: Vincent Starre [mailto:thebitman@comcast.net]
>>
>
>
> The first two points look sound to me.
>
>
>
>> third: I should be allowed to commit a file with
>> mixed-line-ending-types. This would probably involve adding new
>> eol-styles, such as:
>> CRLF-ignore-lone-CR
>> CRLF-remove-lone-CR
>> LF-ignore-lone-CR
>> LF-remove-lone-CR
>> CR-ignore-lone-LF
>> CR-remove-lone-LF
>>
>
>
> I don't see what these gain you over and above leaving svn:eol-style
> unset.
> The whole point of the "CR", "LF", and "CRLF" values is to
> enforce/check a
> particular style on a file. It strikes me as rare that these other
> combinations are needed in practice. (And you left off several
> possibilities, including "CRLF-ignore-lone-CR-remove-lone-LF", for
> instance.)
>
>
The point is: I always want files to be checked out as CRLF(*for
example). Once people I have no control over
get their hands on these files, they will often come back with CRLF
mixed with lone LF's. (often a result of vi
being used to make a quick change)
"native" partially corrects this, but forcing someone to use a single
operating system for each working copy seems
silly. (if they want to see what their change did to the unix build,
they would need to check back in and then update
a seperate copy, or risk eol-style errors when they find out "no, this
broke the unix build, I'll need to change this
one line" and open up vi)
simply not setting it is nothing at all like what I am seeking, either.
See the svnbook section on eol-style for an
explanation of why eol-style is a good thing. The point is: when
someone's editor mangles a file:
1) this can be easily detected(*svn already does this) and corrected,
it would be nice to have this happen on
commit rather than requiring it pre-commit.
2) if it can be easily detected and corrected, such corrections can
be accounted for and running svn diff should be
able to compare these files as they will be comitted (assuming
point 1)
nothing has been "left off"- I said "such as", meaning "here are a
couple examples", and it is obviously not a
complete list. But a complete list being something which would fast
become tedious, I offered a more-
comprehensive method directly below it:
> adding these as seperate lines such as:
> CRLF
> ignore-lone-CR
> remove-lone-LF
>
> would seem more...
but the first method would probably take less code, as I suspect
currently it's saying something along the lines of:
"CRLF? Okay, check to see that all CR and LF characters only come next
to eachother, scan the file and remove all CRs"
and the first method would merely add:
"CRLF-ignore-lone-LF? Okay, check to see that all CRs are next to LFs,
scan the file and remove all CRs"
"CRLF-remove-lone-CR? Okay, check to see that all LFs are next to CRs,
scan the file and remove all CRs"
etc
(*no, I have not actually looked at the code yet)
obviously this would count as data mangling, which is why it would need
to be explicitely set- of course, eol-style in
general is a form of data mangling, so that much doesnt sound like an
issue.
Of course, the one issue I can think of with this would be someone
sharing between MacOS, Unix, AND Windows. A
lone-CR and lone-LF could be seen as CRLF. To those people, I have no
solution. For those using only two styles of
line-endings, I have offered this.
>
>
>> fourth, and obviously not a real issue: why no explicite "binary"
>> eol-style? Sure, it's not needed, but I was thinking along the lines of
>> "make a cmmit hook that disallows commits of files without an eol-style,
>> but then there's one file that really is binary and really does need to
>> be named like that"
>>
>
>
> Is no-value insufficient?
>
>
No it is not. I really thought I had made that clear with "and obviously
not a real issue"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 20 20:35:21 2005