apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn:eol-style for autoconf stuff
Date Tue, 15 Feb 2011 03:17:56 GMT
On 2/14/2011 6:42 PM, Guenter Knauf wrote:
> Bill,
> Am 15.02.2011 00:14, schrieb William A. Rowe Jr.:
>> The answer is to use the correct tool on the correct platform, not to break
>> the line endings for everyone vainly attempting to maintain the files in the
>> text editors of the other platforms.
> please elaborate who are those 'everyone' folks, and what is the correct platform??
> configure & friends are shell scripts - thus every platform which deals with shell
scripts
> should also provide an editor which can edit them, no?

Precisely.  If you want a unix view (on windows) you are using a cvs, ssh, git
etc which treat files as unix text.  Checkout, configure and build all work.
Your editor is vi, or emacs, or gnome edit with unix line end conventions.
When you are working with windows build files out of courtesy and attempting
to get them right, any of your unix editors can manipulate these text files
(in unix convention) so that they will perhaps work once applied

Use a unix line ended source code tree to build on using unix conventions.
We have a tarball for that.

> what I talk about here mainly is windows, and I guess you know well about the situation
on
> that platform ...

What situation?  If you compile using windows conventions on a windows
machine using windows ports of cvs, ssh, git etc, the files you manipulate
are windows line-ended, and you are using windows convention text editors
(or gui environments) to manipulate unix files anticipating that they may
work once someone checks them out on unix and tests them.

Use a windows line ended source code tree to build using windows conventions.

This is a rehash of a rehash of a long decided apr and httpd convention,
one that I have no interest in debating again.  People who want to work
in an environment of "mixed" conventions must be prepared to deal with
the "mishmash" they create.

>> If you are foolish enough to mix vc ports of svn with cyg, or visa versa,
>> you have what is coming to you :)
> yeah, and since there's nowhere a MSYS SVN binary which would do it 'right' I would have
> to either use Cygwin then, or cant work directly from svn, but need to always do a 'svn
> export --native-eol LF' in order to get the configure scripts in 'right' format ...
> 
> so please tell me exactly which platforms may be harmed by 'svn:eol-style LF' for the
> configure scripts; and please dont tell me now that you allways want to maintain these
> scripts from a windows box with notepad - then I will reply that you should use the
> 'right' editor which can handle LF files ... :-)

Because I can't edit the damned file on windows when I am accommodating unix, and
I can't edit the damned file on unix when I am accommodating windows.

This stuff is text, end of discussion, but if you want 100's of posts on the
topic please refer to the archives.

> Please see that I want to find a solution which works for most users with the stuff
> commonly available - and there are a couple of editors available which can handle LF
files
> properly on windows, but so far I have not found a MSYS version of svn, and Cygwin seems
a
> bit overkill just for getting svn only ...

What you are proposing is overkill, handling textual information as a binary
resource, and I'm strongly -1 (if you hadn't noticed).  Sorry for my frustration
if you joined this conversation late.


Mime
View raw message