On Tuesday 30 January 2007 13:15, Oliver Betz wrote:
> Les Mikesell wrote:
>
> [...]
>
> > > That's an option, and a good one: just say no to tools that
> > > care too much about EOL. I work on Windows, and almost all of
> > > the tools I use (all of them that I use more frequently than
> > > once a month) handle CRLF or LF fine. If I came upon a tool
> > > that didn't, I'd consider it a flaw in the tool.
> >
> > Was that intended to be humorous? If you don't want do deal with
>
> I agree with Duncan.
>
> How do you access "non CRLF" files without the help of SVN?
>
> > portability issues, just work on one platform?
>
> No, as Duncan wrote: use the right tools.
>
> > > There are plenty of flawed tools out there, but just don't use
> > > them.
> >
> > Sorry, but most people would chose a revision control system that
> > will handle the job they need to do, not choose their job based
> > on what their revision control system happens to make convenient
> > for them.
>
> You missed the point.
>
> SVN can not protect "flawed" tools from the reality in any
> situation.
>
> Oliver
This is my argument for needing a better feature to handle diverse
text files: Since I am trying to track vendor updates (a very common
case), then
1. I do not have a choice how the vendor or any of his opensource
helpers edit there source, nor what tools they use.
2. This is a strong argument: "reality is that text is represented
differently" everywhere. My conclusion is that we MUST deal with it
in Subversion.
So to just expect svn to crash and burn because one of the files is
mixed EOL styles is NOT dealing with it.
I am surprised this "EOL style" thread is still going on since that is
obvious. Is anyone arguing that svn need NOT be improved in this
area??
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 31 22:35:48 2007