I never had problems with LF line endings in my batch files/source
files/whatever
I am on windows 7 with vs2010.
The only thing whitch troubles me is the linux shell interpreter who can
not live with CR-LF line endings and renames dirs to dir^M.
For god sake let windows out of this, becouse it (currently) works
better with different line endings than linux (currently) does. As you see.
I'm sure it was different in the 80's and 90's.
Back to the topic:
Converting files between different OS is an unnecessary feature to me.
You can convert more accurate if you write your own scripts to do that.
That's like deleting unneeded files out of directories.
I wrote a simple tcl script and qt programm to do that:
http://sourceforge.net/projects/dircln/files/
1. cleandir
2. dos2unix
3. fossil add *
4. fossil commit
5. dos2unix
If someone does not want to use the 5 commands all the time, wrap it
into a shell script.
PS:
Converting files to different line endings is already available on most
systems. Even vs2010 can do it, and it's plugin and macro system is
(almost) one of the best.
Greetings, Louis
Am 07.04.2011 18:55, schrieb Richard Hipp:
On Thu, Apr 7, 2011 at 12:42 PM, Ramon Ribó <[email protected]
<mailto:[email protected]>> wrote:
MacOSX is using UNIX line ending since more than 10 years-ago.
In modern computers, there are two options:
Unix/MacOSX: LF
Also, Solaris, AIX, HPUX, NetBSD, OpenBSD, QNX, etc.
Windows: CR-LF
The odd man out.
I would not see it as a problem that fossil changed line-endings if it
was disabled by default and it could be enabled with something similar
to:
fossil setting ascii-glob "*.c,*.h"
Another thing that would be a bonus for cross-platform development
would be to change the encoding of the text files. In modern Linux it
is utf-8. And in modern Windows, it is a code page that depends on the
country but it is different from utf-8
Notice how everybody else uses utf8 for everything. Only on windows
do we have issues with locale-dependent code pages.
There are countless operating systems available today, each with is
own peccadillos. So why is it always windows that gives trouble? The
more one tries to make code cross-platform, the more one realizes that
windows is the problem child.
I understand that it is more reasonable to implement in a SCM only the
line-ending change, but I wanted to write the encoding problem just
for the record.
Regards
RR
2011/4/7 <[email protected] <mailto:[email protected]>>:
> I would be immensely confused if my SCM was modifying the
contents of
> my source code and/or support documents.
> Given that MacOS has yet another EOL = [CR], it is better for
your own
> code to manage distribution effects.
> Just my opinion.
>
> -Steve
>
> On Thu, Apr 7, 2011 at 11:54 AM, Martin Gagnon <[email protected]
<mailto:[email protected]>> wrote:
>> I know this new feature. But I'm really talking about
converting the line ending, for cross platform development issue.
>>
>> --
>> Martin
>>
>> Le 2011-04-07 à 10:43, Clark Christensen <[email protected]
<mailto:[email protected]>> a écrit :
>>
>>> I'm using fossil version [1d93222627] 2011-03-01 19:04:32 UTC
>>>
>>> With this version, Fossil warns about CRLF line ends on
commit, and allows me to commit anyway, or abort and fix.
>>>
>>> This is a good option for me. Some files are OK with CRLFs
and others are not. I like being able to choose.
>>>
>>> -Clark
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From:Martin Gagnon <[email protected] <mailto:[email protected]>>
>>> To:Fossil Users Mailing List
<[email protected]
<mailto:[email protected]>>
>>> Cc:
>>> Sent:Thursday, April 7, 2011 4:11 AM
>>> Subject:[fossil-users] CRLF conversion on windows
>>>
>>> Hi, Is there any plan for CRLF conversion under windows?
>>>
>>> This would be very usefull for cross platform projects. Especially
>>> when using Visual Studio on the Windows side, which silently
add CRLF
>>> line ending on a LF only file which give you a mixed line
ending file
>>> (got bunch of ^M when editing files with Vim after).
>>>
>>> it could convert text file from CR-LF to LF when committing
and the
>>> oposite on checkout, so this would always keep LF line ending on
>>> repository and the local checkout on windows would have CR-LF line
>>> ending text file. Just like does Git and CVSNT (using Tortoise
CVS at
>>> least).
>>>
>>> Of course this might be dangerous for data corruption when
some binary
>>> file are flag as text file, but this kind of feature would be
off by
>>> default for sure.
>>>
>>> --
>>> Martin
>>> _______________________________________________
>>> fossil-users mailing list
>>> [email protected]
<mailto:[email protected]>
>>>
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>> _______________________________________________
>>> fossil-users mailing list
>>> [email protected]
<mailto:[email protected]>
>>>
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>> _______________________________________________
>> fossil-users mailing list
>> [email protected]
<mailto:[email protected]>
>>
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
> _______________________________________________
> fossil-users mailing list
> [email protected]
<mailto:[email protected]>
>
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
[email protected] <mailto:[email protected]>
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
