--- Jeff Smith <jsmith@robotronics.com> wrote:
> On Monday 05 February 2007 06:45, Frodak wrote:
> > --- "Victor A. Wagner Jr." <vawjr@rudbek.com>
> wrote:
> > > >So how many EOLs are their in "\r\n\r\n\n" is
> that
> > >
> > > 3,
> > >
> > > >4, or 5 blank lines in my text file. Because
> it
> > >
> > > does
> > >
> > > >matter to the formatting of the file. Just
> because
> > >
> > > a
> > >
> > > >c compiler doesn't care, doesn't mean that it
> is
> > >
> > > not
> > >
> > > >important to my perl POD output.
> > >
> > > it's 2 blank lines... the first \r\n is at the
> end
> > > of a non-blank line <sigh>
> >
> > You've disregarded that the file could have mixed
> EOLs
> > from Mac and Unix, only. There for a \r is a new
> > line, and \n is a new line, and therefore had 5
> > newlines. You've assumed to interpret \r\n as a
> > single new line as in DOS.
> >
> > My point is that the number of new lines in a
> mixed
> > EOL format is open to interpretation. Plain and
> > simple.
> >
> > > and, IF your perl program "cares" about it, it's
> > > BROKEN (the comment
> > > that started this entire thread)
> >
> > man perlpod. You'll be enlightened about how the
> > number of blank line can make a difference.
>
>
> OK, From the man:
> > Translators are available for converting Pod to
> various formats like
> > plain text, HTML, man pages, and more.
>
> Hmm.. even requires a "translator" just to convert
> from plain text.
> Translation: the man page claims that your perlpod
> doc is not plain
> text, so DO NOT try to import it with auto-props
> setting
Perl interpretor takes a plain text file.
Perl pod marks up the file and converts the output to
all sorts of output.
You've only demonstrated that you misinterpreted the
material.
Maybe you should try it out yourself, you might learn
something, instead of writing complete non-sense.
> svn:eol-style. Your forseen problem with perlpod is
> irrelevant to
> this discussion.
>
> I hope you can all reboot your brains... it's quite
> refreshing. Helps
> if you, at least in the USA, had a nice long Super
> Bowl party.
>
> Then you'll realize that, hey, if I had a perlpod
> document with mixed
> eol and I imported to svn (with the auto-props we
> are talking about),
> there is no way it could hurt that svn tried to fix
> it the eol style
> because the dang file was already broken... We gain
Which is pure and utter rubbish. Simply put,
subversion is a change control tool. Do you
understand what that means? It is a tool to
accurately track changes in a file. When it imports
the file and trys to normalize the file the EOLs that
it uses, it needs to be accurate so you can get the
same file out. At any version. I'd say that it would
be a piss-poor tool if I imported a file and couldn't
get it out again. Which is what you are suggesting in
saying that it's ok for svn "trying to fix it". I
think you are wrong. I don't think it is OK for svn
to try to fix it.
> nothing by
> crashing instead... hmmmm... your Linux may never
> need a reboot but
> aparently some brains run on Microsoft products.
>
Quite simply, there is no accurate way to determine
the number of EOLs in a mixed EOL format. You have no
way of knowing how badly mangled the file is or what
the author intended when they botched the file.
Therefore you don't know the number of blank lines.
You may want a tool that will try and guess. OK.
Fine. I don't believe that is within scope of
subversion.
The notion put forward during this thread that there
is no difference between 1 EOL or 2 EOLs is baffling
and utter BS. Even in a text editor you can see the
difference, it's called double-spacing.
Tools may or may not care about the number of blank
lines in a file. The C compiler does not care; The
Perl POD extractor does care. Plain and simple.
That's just how they work. The documentation that
comes with these tools state this.
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 5 18:53:29 2007