From: Fay J. F Dr C. U. AFSEO/SK <joh...@eg...> - 2006-09-26 16:03:49
|
Joe, I don't think it's necessary to set explicitly the line endings on *all* files. My Windows "TortoiseSVN" choked when I tried to send a source file that had a mixture of DOS and Unix line endings. The only place that it is necessary (in my opinion, at the moment) to specify line endings is for the MSVC workspace and project files. Probably we will need to add the Watcom files to the list when we get to them. Otherwise SVN will download text files to your native environment and you can carry on as you like. John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group 850-883-1294 joh...@eg... -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Joe Krahn Sent: Tuesday, September 26, 2006 10:47 AM To: FreeGLUT developers list Subject: [Freeglut-developer] SVN line ending properties I converted LF to CR/LF on my copy of the project files, but SVN saw this as no change. I now realize that SVN has some somewhat confusing features for line endings. It tries to convert text file line endings to the local 'native' format. I'm using Cygwin svn, so I'm guessing it thinks I want all of my files with UNIX line endings. I think this idea for line-end conversion does more harm than good. The line-end conversion stuff will just cause unexpected difference between SVN files and dowloaded .zip/.tar.gz files. Anyhow, to fix this, I added svn property flags to define CR/LF line endings on the project files, which is committed to the repository. Maybe we should explicitly set line endings on all svn files? Joe ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F Dr C. U. AFSEO/SK <joh...@eg...> - 2006-10-23 13:24:19
|
Sven, I think the problem is even smaller than you have said. If I remember correctly, I checked out some C files with TortoiseSVN in Windows(that I am sure of), edited them under Linux with VI, and checked them back in with TortoiseSVN under Windows. Files that only had differences in line endings were not flagged as having changed. The problem comes with MSVC project and workspace files. They need the DOS line endings and so checking them out under Linux would break them. John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group 850-883-1294 joh...@eg... -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Sven Panne Sent: Saturday, October 21, 2006 8:21 AM To: fre...@li... Cc: Joe Krahn Subject: Re: [Freeglut-developer] SVN line ending properties If I see things correctly, the "line ending problem" is not a problem at all: All files, including M$ workspace/solution/project files, get no special treatment at all (i.e. their svn:eol-style is native). The only thing which has to be avoided like hell is mixing svn clients and editors which have a different understanding of line endings. Therefore: * If you use Cygwin's svn client, use Cygwins XEmacs/vi/... * If you use TortoiseSVN, use Visual Studio/a native Win32 XEmacs/... * Under Linux/*BSD/... you can do everything you like (well, apart from things like checking out with a Linux commandline client and edit with a DOS editor running with Wine ;-) This way one can even edit Visual Studio workspace files under Linux and get a sensible "svn diff". Or did I miss something? Cheers, S. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Sven P. <sve...@ae...> - 2006-10-24 07:31:03
|
Am Montag, 23. Oktober 2006 15:22 schrieb Fay John F Dr CTR USAF AFSEO/SK: > I think the problem is even smaller than you have said. If I > remember correctly, I checked out some C files with TortoiseSVN in > Windows(that I am sure of), edited them under Linux with VI, and checked > them back in with TortoiseSVN under Windows. Files that only had > differences in line endings were not flagged as having changed. Hmmm, I've never heard of that feature and have to check that for myself. Anyway, checking out under one OS and editing/committing it under a different one is generally a recipe for desaster. freeglut is not exactly in the 1GB area, where space could be a problem. > The problem comes with MSVC project and workspace files. They need > the DOS line endings and so checking them out under Linux would break them. No, this is not a problem at all: Those project/workspace/... files are just plain old text files, but Visual Studio is just too dumb to read them when they don't follow the CR/LF convention. But what you can do is e.g. generate a project file with Visual Studio, check it in with TortoiseSVN, check it out under Linux (seeing only Unix-style line endings), edit it there, and check it back in. The next time you update your Windows copy with TortoiseSVN, you get exactly what you want (i.e. the changes, but this time with DOS-style line endings). I've done this several time in the past and it works perfectly. The only tricky part is how source distributions are built, because we have to make sure that they contain DOS-style Visual Studio files. One could argue that because of this, fixing the line ending style for those files to DOS is the right way. Hand-editing those kind of files happens only rarely, and XEmacs and friends are clever enough to follow any convention when the need arises. There is no deep black magic going on in SVN, and file properties should only be used when binary files are involved which SVN doesn't recognize as such. The simple rule is: *Never* mix programs which have a different understanding of line endings, because your local SVN will let you see everything in your local convention. Just to re-iterate: a) DOS-style: Visual Studio, WIndows text editors, TortoiseSVN, ... b) Unix-style: Unix text editors, svn commandline clients running under something *nix-like (including the one coming with Cygwin), ... The mistake Joe made was simply mixing a) and b) and trying to make a (wrong) workaround for that mistake. I think that most of us made the same mistake at least once in the past, I definitely did! :-) Cheers, S. |
From: steve <sjb...@ai...> - 2006-10-24 11:46:30
|
Am Montag, 23. Oktober 2006 15:22 schrieb Fay John F Dr CTR USAF AFSEO/SK: > I think the problem is even smaller than you have said. If I > remember correctly, I checked out some C files with TortoiseSVN in > Windows(that I am sure of), edited them under Linux with VI, and checked > them back in with TortoiseSVN under Windows. Files that only had > differences in line endings were not flagged as having changed. You really are asking for trouble doing that kind of thing. I think there is a way (at least under the Linux SVN client) to tell it to use line endings other than 'native' for that OS. If you absolutely have to checkout under Windows and edit under Linux, then you need to be 100% sure that the Windows client checks out and in again with UNIX-style line endings. Worst case scenario is that you totally mess up the line endings for everyone else! > The problem comes with MSVC project and workspace files. They need > the DOS line endings and so checking them out under Linux would break them. No - that's not the problem because when they are checked back in again, then checked out on a Windows machine, SVN puts the line endings back in in the way Windows wants them to be. The only problem is when we make source releases under Linux in which case those files get stuffed into a tarball on a Linux machine - which means that inside the tarball they have incorrect line endings for Windows. The right fix for that is to flag them as binary files - which the SVN system can deal with without line ending translations. The only problem with THAT is if someone edits one of the Windows-only project/workspace files under Linux. That's not a very likely scenario though - and most Linux editors are careful to preserve foreign line endings (although possibly not if you add more lines to the file in a Linux editor) - so this is quite manageable in practical situations. Another possibility would be to write something into the "./configure" mechanism to check and fix those project files whenever you do a "make dist" to construct a distribution tarball. Under Linux or Cygwin, that would be easily done with a call to 'tr' or something. We don't want to do that routinely on every checkout because it would cause the files to be 'touched' each time and they'd clutter up the revision history and slow down the commit/checkout process. |