From: "Karl Fogel" <kfogel@newton.ch.collab.net>
Sent: Wednesday, February 20, 2002 11:09 PM
> "Faller, Gyula" <gfaller@graphisoft.hu> writes:
> > I downloaded subversion-r1302 tarball yesterday, tried to load the
> > subversion.dsw into VisualStudio 6.0 and tried to build it. But the VS
> > ceased to load the apr.dsp. It is said it is not a VS dsp. I look into it,
> > and converted it to MSDOS EOL from Unix EOL, and everything works fine.
> > So I suggest to convert apr.dsp to DOS format in the tarball to make
> > WIndows folks life easier.
>
> It looks like apr.dsp lives in the apr/ subdirectory. So unless
> Subversion generates it (?), this is something APR would need to
> solve. I've CC'd this to the `dev@apr.apache.org' mailing list...
APR has nothing to solve.
Text files on Win32 end in CR/LF. All Of Them. We don't expect Unix users to
have to put up ^Ms when they check files out of repositories. Nor should Unix
[or Cygwin users] expect we need to put up with LF ended files. Mac [Classic]
lineended files? On that platform, sure! Please ... each platform defines text
its own way. CVS has a very clear concept of text files, and how to handle them,
each port assumes reponsibility for outputing that platform's text format and
checking in text files in a Unix-consistent \n lineended format. I certainly hope
SVN continues this concept, and doesn't force us to macerate it as the cygwin-cvs
community has done. [cygwin's cvs is -great- for checking out files for use in
the cygwin environment! Don't get me wrong - it's just the -wrong- choice for
checking out files for win32 development.]
If you download a tarball, don't expect it to build on Win32. If you are building
Cygwin, you don't need the .dsp's in the first place. If you are building in
DevStudio, it's rather nice to be able to edit the -sources- while you are at it.
The Apache project has begun making a .zip file available of packages that are
dos-lineended. This has proven quite effective.
Why the diatribe?
1. Unix hackers to the APR project have done an admirable job of adding source
to Makefile.in -and- the Win32 .dsp files! How is this possible? Because
they are simple text, and without binary ^M crap these contributors stand
a reasonable chance of not creating a foobarred file.
2. Win32 hackers who use Win32 tools, e.g. cvs or wincvs have a fighting chance
of checking out valid files. Text files with \r\n lineends usually end up
as \r\r\n by the time all is said and done.
3. The other 'alternative', checking in .dsp files as binary, isn't [a valid
alternative.]
Since cvs commit logs won't carry revision information, nobody has a clue
what 'magic' goes on in those .dsp files. It only takes an APR hacker to
read some four commit messages before they have the gist of keeping those
silly Win32 things up-to-date.
Binary .dsp's make following the revision history an absolute nightmare.
CVS diff'ing or patch'ing 'binary' .dsp files??? Forget it.
There is a simple option for an RM wrapping a .zip file on Win32 [the converse
doesn't work - explain in a moment.] I'd hacked a lineends.pl file a good time
ago to catch text yet leave nearly any binary file alone. It will detect stray
\r occurances or mismatching numbers of \r characters preceeding any \n, and
throw up [yes - you can override when the file's been mangled.] Best of all,
it is Unix/Win32 compatible, and could probably be made compatible with most
other formats. It simply presumes stdout in text mode knows best, unless you
override the behavior (--cr or --nocr will explicitly convert the files as
instructed.)
So using lineends.pl --cr you can prepare a '.zip' ball targeting win32 on unix
for Info-zip or your favorite unix .zip utility, as part of an auto-packaging
schema. I wish the alternative worked, but file modes get very wonky creating
a tarball on win32 and attempting to unpack it with appropriate rw[x]r-[x]r-[x]
bits set.
Given the -portability- issues involved, I've finally decided just to drop the
lineends.pl into apr/build. Any objections, please holler. Any improvements,
please feel free to commit.
Bill
---------------------------------------------------------------------
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:37:09 2006