Annoying CVS issue

[mandrav]

Hi all,

I have an issue which has never happened to me before, and I 'd like to ask about it the more proficient cvs users then me.
(the following apply to me; can't say about other devs)

Up to now, development of C::B, was done primarily on windows. Lately though, with the linux version being really stable and usable , I 'm doing enough work (and testing) in linux too (a dream comes true ).
The problem I have is with line-endings (EOL).
If I commit changes to a file in linux, when I open it in windows it has one blank line every other line. For example:

Code

#include <wx/wx.h>
#include <wx/log.h>
#include <wx/intl.h>
#include <whatever.h>

becomes:

Code

#include <wx/wx.h>

#include <wx/log.h>

#include <wx/intl.h>

#include <whatever.h>

which is pretty annoying.
Now, I guess this has to do with the automatic EOL conversion done by CVS, although I must say that I only recently noticed it so it may as well be a bug in the auto-conversion of EOL added in C::B (maybe Rick knows about this?)...

Anyone knows a way around this?

[thomas]

At the risk of being cheeky... use Subversion

According to "The Cederqvist", giving -kb when adding new files should make CVS behave, too (have not tested, though).


EDIT:
And another thing possible...
It may actually be that CVS is working *properly*. Check the editor which you are using under Linux. Some editors offer a "feature" to save with non-native line endings, so if your Linux editor is configured to write CR+LF in an attempt to be "compatible", and CVS (correctly) inserts a LF after CR because you migrate from Linux to Windows, then you may get that very same effect. In that case, simply change the editor's preferences to "use CR".

[mandrav]

EDIT:
And another thing possible...
It may actually be that CVS is working *properly*. Check the editor which you are using under Linux. Some editors offer a "feature" to save with non-native line endings, so if your Linux editor is configured to write CR+LF in an attempt to be "compatible", and CVS (correctly) inserts a LF after CR because you migrate from Linux to Windows, then you may get that very same effect. In that case, simply change the editor's preferences to "use CR".

That's what I thought. Thanks, I 'll try it

[mandrav]

At the risk of being cheeky... use Subversion

I though you 'd say that
Anyway, as I 've said before, I *love* subversion but sf.net doesn't support it...
(don't even think of moving the repository now )

[rickg22]

Well, the option I added to set the line endings mode was taken directly from scintilla. I see no reason why files modified in Linux would be different from those in Windows (see the editor preferences, EOL mode)

So I'm sure it's a CVS setting.

[thomas]

Rick:
To avoid the problem that Linux users will get disturbing double-linefeeds when reading Windows files, CVS (and SVN, too) fiddle with line breaks, adding and removing LFs between architectures as needed. This is actually a good feature, but it relies on the assumption that files are in "native" format (not true for SVN because you can configure that on a per-file base).
However, since Yiannis is getting double-LFs, my idea was that possibly he was using his editor set to "CR & LF", which would write files the Windows way. While being able to read and write data in non-native formats is a cool feature on the one hand side (there is nothing more annoying than opening a Unix file with Notepad...), it is strictly speaking incorrect.
CVS, when reading that file, would know that it is running on Linux. Since it makes sense that a file is in "native" format, CVS woud therefore assume that it has to insert LF after CR, which is perfectly logical. Now it depends on how smart CVS really is, it may either only insert a LF if it is missing, or (and so I believe) simply insert a LF after every CR.
The options you added to line endings mode are certainly correct. But while they are correct, their usage is not, because it is not what other programs will assume.


Yiannis:
Don't even think about migrating? What is so scary about running cvs2svn? It should really not cause too much grief? I mean, you can say "no" after thinking about it, but not think about it at all?
There are even GPLed hook scripts available that allow back-versioning to a read-only CVS repository, so while committing to SVN, people can still check out via CVS if they want.

[mandrav]

Yiannis:
Don't even think about migrating? What is so scary about running cvs2svn? It should really not cause too much grief? I mean, you can say "no" after thinking about it, but not think about it at all?
There are even GPLed hook scripts available that allow back-versioning to a read-only CVS repository, so while committing to SVN, people can still check out via CVS if they want.

I 'm not talking about migrating the repository from CVS to SVN, but migrating from SF to Berlios (for example). It's too much for now

[mandrav]

Well, the option I added to set the line endings mode was taken directly from scintilla. I see no reason why files modified in Linux would be different from those in Windows (see the editor preferences, EOL mode)

So I'm sure it's a CVS setting.

Rick, don't be so sure because this only happens for files I edit using C::B.
If edit files using gedit and commit the changes, no problem.
So I 'm fairly sure it's a C::B bug 

Another thing I noticed and it might be related is this:
When I open a file in Linux C::B and immediately close it (i.e. don't do anything), C::B asks me to save it although it isn't visually marked as modified  :shock:
I 'm pretty sure it has to do with some automatic EOL conversion taking place...

[rickg22]

Hmmm... yes, I think you're right.

Anyway, you can try setting the EOL mode in Codeblocks to "LF" in your linux build (editor settings)

[mandrav]

Tried that. No luck...

[mandrav]

Found it and fixed it.
A new editor option was added: "Ensure consistent EOL".
This used to be hardcoded to "true" by default and caused a EOL-conversion for the document when saved. Now it's a separate option, off by default, and works as expected

[rickg22]

Hmmm... that's very interesting. Anyway this option enabled in Linux was what was causing the problem? (Now that i think of it, is it safe to have it in windows?)

[mandrav]

Hmmm... that's very interesting. Anyway this option enabled in Linux was what was causing the problem? (Now that i think of it, is it safe to have it in windows?)

As I said, when saving the file it forced a conversion of EOLs. This caused the problems I have described...
I don't want to be forced anything by the editor, so I added the option. Simple as that

[knue]

Hi, I am devloping a project on linux und windows and worked with the 1.0-RC1 version and had the same problems with EOLs. I assumed that this is a CB because I didnt have problems when using other editors. Now I am using a newer CVS-Verions which has the "ensure consistent EOL" options. But I am totally confused. Here my questions:
1. How does Window handle EOL?
2. What is the UNIX standard?
3. What does CVS with this?
4. How do I have to setup CB in win to handle that properly?
5. How do I have to setup CB in linux to handle that properly?
6. Is there a tool to convert EOLs so I can fix the "corrupt" files of my project?

Thx for replying

[thomas]

1. \r\n (corrected by Rick)
2. \n
3. Insert \r before \n when converting from Linux to Windows, and stripping \r in the opposite case
4.+5. Ask Rick   But I believe you must DISABLE that option
6. unix2dos (comes with MinGW and is a standard tool under Linux)