Automated management of Debugger Configuration and Project Settings.

Sergej,

A couple possible solutions:

1. It is possible to have multiple .ccxml files in a project.  This is the file that contains the debugger settings (emulator used...).  Individual users then choose which one they want to launch with.
2. You can store .ccxml files locally outside of your source control system.  When you create a .ccxml file you can specify to create it in a common folder.  Users could then maintain their own .ccxml files separately from the project.  They can be launched from the target configuration view, and then you load the .out from your project.

Hi, John.

I'm not sure you understood the problem.

We all have several CCXML files. Each is with the preferred settings for each developer.

But the file .ccsproject holds the line:

<connection value="common/targetdb/connections/BH-USB560m_20pin_Connection.xml"/>

And at every commit we should solve the conflicts because all of us are with different debuggers. The workspace parameters had been used at prev. version of CCS (v 5.0 i believe). Then we had a chance to merge our source files and other stuff files. But not with current version of CCS.

At general the CCS is focused on the personal development not on the team development.

Sergej,

I understand what you are saying.

Those are the values in the .ccsproject file are those used to create the project by the project wizard.  When you set those values it will result in a .ccxml file and .cmd file being added to your project.  It will also change the .cproject file as it reapplies device specific build options.

What I am saying is don't touch those settings to personalize your debugger if you are working in a team environment.

You can have multiple .ccxml files in your project at the same time (managed as source files).  Don't create a new one by changing the Project properties, create a new one by right clicking on the project and selecting New -> Target Configuration.  Or by just copying the files into the project if you already have them.

Alternatively users can create the files outside of the project structure if they do not need them to be managed as part of the project.

Regards,

John

hi, John.

I'm not saying "it is not possible to use the CCS in a team". I'm saying it's complicated. The CCS manages the properties/CMD files/CCXML files (active/defaults).

It's enough to switch the configuration and get the error while debugging (because of changes in the configuration).

The prev. version of CCS (5.0 i believe) didn't manage these settings. We had a chance to create an "extra" project. Store all the setting and commit all of these.

It's not like the CCS 5.2. We're forced to do the same work at every switch of configuration / commit of project / etc.

My proposal is to revert the changes back like these was in CCS 4.2 or somewhere there.

Hi, Baltasar.

Thank you. It's really important thing.