User forums > Help
Issue about saving the cbp project file
oBFusCATed:
--- Quote from: thomas on July 29, 2013, 01:37:33 pm ---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.
--- End quote ---
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 :P ::)
.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!
--- Quote from: thomas on July 29, 2013, 01:37:33 pm ---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.
--- End quote ---
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:
--- Quote from: oBFusCATed on July 29, 2013, 01:58:20 pm ---.cbp is not a binary file and this is a good feature!
--- End quote ---
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:
--- Quote from: oBFusCATed on July 29, 2013, 02:02:18 pm ---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...
--- End quote ---
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:
--- Quote from: thomas on July 29, 2013, 02:19:21 pm ---On the contrary, cbp is a binary file.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version