Issue about saving the cbp project file

[oBFusCATed]

Look, if GIT is too stupid to handle files it shouldn't touch at all, then that's sad. In particular because GIT is a Linux revision control system, and these are Unix line endings. But frankly, it's GIT's problem, not ours. GIT has no reason to look into .cbp files at all, for all it knows, these are binary files, just like .conf files.

You're too aggressive here! I guess there is some part of your brain that goes in rage-total-destruction-mode when someone mentions GIT 

.cbp is not a binary file and this is a good feature! If we wanted people to know that it is a binary file we would have made it such!

There was a similar issue with people editing .conf files in a text editor and complaining that they were broken afterwards. Because, hey, if something looks like you could edit it, then it is totally necessary that you do. I was at some point tempted to rot13 encode config files only for that reason.

But you haven't, because the cbp is better to be a text file.
If the user breaks its file by editing it, then it is totally his fault.
If C::B does something strange on invalid input then it's C::B's fault.

[oBFusCATed]

ollydbg:
I think there is a way to tell git that the file will be in UNIX EOL mode.
As far as I know git doesn't care much about the EOL. Currently at work I'm using it only Linux with a repo that is in EOL=CRLF and it works ok.
It print warnings but they are harmless.

Also git as far as I know never changes the files. If the file is create in EOL=LF  then it is stored as such, if it is in EOL=CRLF then it is stored as such.
But I may be wrong here, because I've not delved too much into this problem...

[thomas]

.cbp is not a binary file and this is a good feature!

On the contrary, cbp is a binary file. It is the file that Code::Blocks chooses to store its projects in, using an unspecified, proprietary, and entirely unknown format.
Only by coincidence, this format contains a structure that looks like XML, and only by coincidence there are human-readable strings and line breaks in it.

Users and tools are not meant to look at this file, interprete its contents, or even modify it (incidentially, the format was chosen so the Subversion diff viewer works just fine with cbp files as it is, but that doesn't change the fact that it's a binary file).

[stahta01]

ollydbg:
I think there is a way to tell git that the file will be in UNIX EOL mode.
As far as I know git doesn't care much about the EOL. Currently at work I'm using it only Linux with a repo that is in EOL=CRLF and it works ok.
It print warnings but they are harmless.

Also git as far as I know never changes the files. If the file is create in EOL=LF  then it is stored as such, if it is in EOL=CRLF then it is stored as such.
But I may be wrong here, because I've not delved too much into this problem...

Info about Git EOL settings; there appears to be at least 3 different settings that are changeable.

http://git-scm.com/docs/gitattributes#_checking-out_and_checking-in

I know in SVN, the CB way works acceptable in how EOL is done.
Not, sure if adding a EOL for cbp files option to CB is a good idea or not.

Tim S.

[oBFusCATed]

On the contrary, cbp is a binary file.

Of course it is not, at least in users or my perspective. It is a pure text/xml file. You can pretend it is not, but you've missed the moment to make it binary.
One example of a binary file in xml form is the files generated by visual studio. They are true binary and non-VCS friendly.

p.s. keep in mind that at the moment there is at lease one feature that has no ui and the users must edit the cbp
p.p.s. users want to look at the content of the file, in order to review patches others have pushed to the repos.

[ollydbg]

Thanks all the replies.
Here is my point:
1, cbp file should be a non-binary file, it makes version control system and code reviewer happy.
2, I just check the eol property of the cbp file in my svn repo, it was "native", which means if the file in the svn server is stored in LF, when it was checkout in Windows system, it use CRLF. When you modify the cbp under C::B, the cbp file was saved in LF, but I believe when I did a commit on the svn, it just did the correct conversion of EOL.
3, It is the same thing as Git, expect that Git print some warning message (maybe svn commit also print some warning, but I don't know), but it is harmless.
I can live with those warnings.

[oBFusCATed]

2, I just check the eol property of the cbp file in my svn repo, it was "native", which means if the file in the svn server is stored in LF, when it was checkout in Windows system, it use CRLF. When you modify the cbp under C::B, the cbp file was saved in LF, but I believe when I did a commit on the svn, it just did the correct conversion of EOL.

If this is the case, our svn is set in a wrong way.

[ollydbg]

2, I just check the eol property of the cbp file in my svn repo, it was "native", which means if the file in the svn server is stored in LF, when it was checkout in Windows system, it use CRLF. When you modify the cbp under C::B, the cbp file was saved in LF, but I believe when I did a commit on the svn, it just did the correct conversion of EOL.

If this is the case, our svn is set in a wrong way.

This reveals another issue, if we modify the cbp file eol svn property to "LF" (see: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style), then when a patch containing a change on both a cbp and a cpp, what will the generated patch files' eol be? Mixed LF and CRLF (LF for patch hunks of cbp, and CRLF for patch hunks for cpps)? 

[stahta01]

This reveals another issue, if we modify the cbp file eol svn property to "LF" (see: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style), then when a patch containing a change on both a cbp and a cpp, what will the generated patch files' eol be? Mixed LF and CRLF (LF for patch hunks of cbp, and CRLF for patch hunks for cpps)? 

Not from me since I use "--extensions --ignore-eol-style" in creating my patches.

Tim S.