William A. Rowe, Jr. wrote:
At 04:44 PM 12/9/2004, Branko ÃÅibej wrote:
* because 'patch' should always 'just work'
It has for me. I've not yet seen a version of patch (on Unix) that would get confused by the CRs.
Apparently you don't do AIX 4.3, HP/UX and other twisted
varients lol.
As a matter of fact, I do. Yet I have seen no such problems. But I admit
I use Emacs everywhere, and the rest of the world isn't so enlightened. :-)
* because other platform maintainers may add/delete sources
So? They can use a non-broken editor, such as Emacs, vim, etc.
It's unix'es editors job to recognize silly MS conventions?
I consider any editor that doesn't maintain a file's end-of-line style
to be broken, whether on Unix or elsewhere.
* because .dsp/.dsw are only the 'obvious' problem. The less
obvious issue is that the compiler gets entirely twisted about
what 'line number' of the sources corresponds to a given
symbol, and the debugging support becomes worthless with \n
terminated sources.
Huh? Which compiler? And what does that have to do with the
format of .dsp files?
Has to do with the format of all text files built by MS cl.
A broken build is a broken build, whether it just won't build
at all, or when the build results are mildly bogus by being
impossible to debug/trace etc.
I still don't understand what the problem is. I've built files with MS
cl that contain \n instead of \r\n, and I've never noticed anything
wrong with the debug info.
I'm coming to learn that, though I'm still not reassured.
Better point though; svn unix users (or the cygwin port users)
can add a flag to their checkout to grab files as CRLF. There's
no need to even use the win32 svn port to accomplish this.
Yes but that will affect _all_ text files, which might not be what you want.
I'd like to see concrete examples of problems that can't be worked around. This hand-waving and inventing problems bores me. I've been using Subversion with CRLF eol-style set on .dsp files for years, from both Windows and Unix, and I've never had a single problem.
I deal with about 6 different 'edgy' unicies, which aren't
nearly as forgiving as Linux.
There are alot of broken projects which focus only on the expected
Linux/OSX/Win32/Solaris8+ and don't even know what an .sl file is,
year old projects who can't grok .dylib files, etc... while our
APR project attempts to be wildly more cross platform.
Well, we can hope. :-)
Simple fact (again, cvs, and svn may prove better) - In order to
patch mixed source and .dsp files as one update against, say,
cvs-php4, it's impossible to apply the same patch, checked out
on hpux, linux, solaris, and win32. It works just dandy on win32,
they all come out with cr/lf's, patches included. Try that on
hpux for example, and it chokes.
Such cross-platform patches will always be a problem, and they really
have nothing to do with Subversion or the eol-style settings. Possibly
an "svn patch" command could fix that, but we're quite a ways from that.
But much worse, try a cvs diff on unix, and you end up with
a mess of ^M's on the patch. Now, commit that patch, check
it out on win32, and you end up with the beautiful CR/CR/LF
line endings. This isn't getting any prettier.
Yes, this happens with CVS. Like I said, SVN is quite a bit smarter than
that. If you set the svn:eol-style property, it won't let you commit
unless the file's contents conform to what that prop says they should be.
SVN has it's own issues. Do an svn diff of a text file (native.)
Guess what? The resulting patch isn't even native! On win32
I'm left with LF delimited deltas.
Huh? Which version of SVN? I think we fixed that bug a while ago. If
not, tell us about it. Please. :-)
Obviously, I won't be ditching
lineends.pl any time soon.
The [EMAIL PROTECTED] project's httpd/mod_aspdotnet repository is
actually a nice place to play with these issues; we only build
that module on Win32, so almost every issue I mentioned is moot.
I'm struggling to see how svn is helping us and what it can do
to seriously help Win32 users.
-- Brane
