> 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. >
The reality is that if you count any electronic device that can contain an OS, probably UNIX is included in more devices than Windows (or it will do in the future when even the house fridge will contain a processor running linux). But if you only count the devices that can potencially run "fossil", 9 for every 10 of them are running Windows and are having the CR-LF problem as well as the code page problem. An you know, big brother always is right, isn't it? RR 2011/4/7 Richard Hipp <[email protected]>: > > > On Thu, Apr 7, 2011 at 12:42 PM, Ramon Ribó <[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]>: >> > 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]> 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]> 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]> >> >>> To:Fossil Users Mailing List <[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] >> >>> 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 >> >> _______________________________________________ >> >> 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 >> > >> _______________________________________________ >> fossil-users mailing list >> [email protected] >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > -- > D. Richard Hipp > [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
