• Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 681 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS 5 checking in files from the Debug or Release directory

BadMonkey
Expert 2090 points


From TI Wiki:

The following files and folders should not be checked into source control:

  • \Debug or \Release \<configuration name> folder
  • .xdchelp
  • \.config folder
  • \.launches folder

=============================================

Although the TI Wiki at "http://processors.wiki.ti.com/index.php/Source_control_with_CCS" states not to save anything from the Debug or Release directory into revision control, I actually check the .hex & .map files.

Without the .hex file, you can not verify that the exact same code was built whether buy a different developer, a new PC, or just sometime later after updates have been made to CCS. So, IMHO, the Wiki should be updated to reflect this concept.

That very concept was touted by TI in SPRA372.pdf,, May 2002, no revision number, page 1:

With Code Composer Studio checked into a version control system, developers can maintain a high degree of control over tools available for builds. The developer can now produce bit-exact versions of production code.


However, without the output file available in RCS, verification of the exact bit copy is not readily available. Yes, at my company, I can get a copy of it from the manufacturing management system which is clunky. Maybe for some large scale jobs it would not makes sense, but for an MSP430, 2812, 2809, or 28035, we always check in the .hex file and .map files. They are just not that large to make a difference to the RCS.

Again, just my 2-cents worth.

Regards,

Jim

  • TI__Guru**** 162935 points

    Jim,

    You wouldn't want to have them as source files that are checked in as part of the project itself as you would have to have them checked out just to build.  Which wouldn't work in a multi user environment.  However archiving those files in source control does make sense for they reasons you state.  I would just do it separately from CCS.

    Regards,

    John

  • in reply to JohnS
    Expert 2090 points

    Hi John,

    Thanks for the reply. Here are further thoughts based on your input.

    We actually do check them in a multi-user environment for over 10 years now. We do team development and it allows another developer to check out the source files and the deliverable file. Then a Rebuild All can be performed. Because the output file is part of the file set, RCS will flag it if it is not a match. We use StarTeam and the user is connected live to the server, not a cache. ST can also set to use MD5 checksum for the file compare status. If the file doesn't match, you will see it. Then there is something wrong with that developer's tool chain and we need to figure it out and correct it.


    Like I say for processors that run a LInux distro, this may not be feasable. But, for the smaller controllers, our output file is 250k -300k, it works great to have it as part of the source archive. Further, in our lab environment, other groups and technicians will come to us to get firmware or program a board. We can just whatever version needed from RCS.

    As you mentioned, It could be checked into RCS in a different project or area. But, checking it in with the source files provides referential integrity between the two.

    Regards,

    Jim