See http://www.keil.com/forum/56892/
"The project file should have been 100% focused on the rules required to perform the similar task of a Makefile. Everything else should have been optional information stored in separate files that doesn't need to be version-controlled and that can be auto-created if missing"
I entirely agree. It seems that Keil have totally broken the Project File arrangement as far as Version control goes.
:-(
And how is it intended that the Pack status should be controlled??
And what is the official recommendation for source code management of the different files, so that a developer can check in a complete project and a different developer then check out the project and be able to build using the same options/versions etc. But without all the time getting large amounts of SCM differences from open editor files, size of windows etc?
I feel that Keil should have a whitepaper available about this critical part of how to use the Keil tools. And if you do get into troubles writing that whitepaper, then that would indicate that there might be issues with the separation of information in the different uVision project files.
" ... about this critical part of how to use the Keil tools. And if you do get into troubles writing that whitepaper, then that would indicate that there might be issues with the separation of information in the different uVision project files."
Absolutely!
Then you might see things like the fact that the filetype descriptions are wrong; eg:
http://www.keil.com/support/man/docs/uv4/uv4_b_filetypes.htm
"*.UVOPTX: µVision5 project options. Contains the settings for the debugger, trace configuration, breakpoints, currently open files, ... . This mandatory XML file can be shared in a work-group."
Actually, it does not contain anything about "currently open files" - that's in the project.uvguix.<user> "user preferences" file.
However, it does show which groups in the Project explorer are expanded or collapsed - which are, surely, "user preferences" and should **not** be in a shared workgroup file!?!?
And Breakpoints should, surely, **not** be in a shared workgroup file!?!?
Hello Per,
have you seen our Application Note 279 ( http://www.keil.com/appnotes/docs/apnt_279.asp )? This is a first version of our way of looking at project revisioning using Git. I would be very happy to get some feedback on AN279.
Kind regards,
Christopher
Thank you. I'll take a closer look at that application note.