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.

CCSV5, revision control and portable projects

(Forgive the duplicate posting, I had added this to the tail end of an old thread, but I'm not sure anyone's reading it)

I'm having some trouble sharing projects through an RCS (we're using subversion). I'm trying to figure out what I'm missing.

We have the following setup (abstracted a bit):

I have the CCS project definition

\$(DEVELOPMENT_ROOT)\workspace\MY_PROJECT

and the source files

\$(DEVELOPMENT_ROOT)\MY_SRC

This local directory tree is under source control, but some individual files may not be.

Source control for the source files are not a problem. The only concern is the project itself.

So I can create a project that used linked resources, based on a local definition of DEVELOPMENT_ROOT. However this absolute path definition appears in both .project and .cproject files in the MY_PROJECT directory. So when I put the project under source, it's not really portable any more.

If Alice creates the project and puts these files under control, Bob can then check out the project. Bob can edit the definition of the DEVELOPMENT_ROOT variable, and build the project. But this changes the project definitions in .project and .cproject. and from a source-control perspective, this tree has now changed. If Bob adds another linked file to the project definition, and commits this change to the project, when Alice updates her copy, it will also overwrite the definition of DEVELOPMENT_ROOT.

I do want the project settings and file list (linked resources) to be under source control. I do not want the variable definitions to be. Is there a way to do this?

Thanks for your help.

John

  • Hi John,

    John Enright said:
    I do want the project settings and file list (linked resources) to be under source control. I do not want the variable definitions to be. Is there a way to do this?

    One option is to remove the linked resource path variable definition from the project level (which is stored in the project files) to the workspace level. Thus you'd avoid all those headaches the project files constantly being updated. You can also create a ini file to auto add the variable definitions to the workspace on project import.

    See the attached PDF for more details.

    Thanks

    ki

    5050.CCSv5_Variables_project_vs_workspace.pdf

  • Thanks Ki-Soo.

    Okay that's exactly what I was looking for.

    Just a few last notes:

    • The PDF says that CCS will automatically read a vars.ini file "at the root location". Is that the root of the workspace? I put my vars.ini at the workspace root, but it didn't automatically load. I had to import it again manually. Not a big deal
    • When moving the scope of the variable, I found that it's crucial that you remove the macros.ini or macros.initial from out of the project directory, or else the variable will appear at the project scope.
    • I truly appreciate the help with this but the means of accomplishing the solution was not remotely intuitive or easily discovered. There are oblique mention of workspace-scope variables in the documentation, but no real instructions on how to create them.
    • Could we work some of these instructions into the "Portable Project" documentation? 

    Thanks again.

    John

  • Hi John,

    John Enright said:
    The PDF says that CCS will automatically read a vars.ini file "at the root location". Is that the root of the workspace? I put my vars.ini at the workspace root, but it didn't automatically load. I had to import it again manually. Not a big deal

    It is the root of the project folder. Your project folder root is the same location as .ccsproject, .cproject, .project files

    John Enright said:
    When moving the scope of the variable, I found that it's crucial that you remove the macros.ini or macros.initial from out of the project directory, or else the variable will appear at the project scope.

    where did you get your macros.* files from?

    John Enright said:
    I truly appreciate the help with this but the means of accomplishing the solution was not remotely intuitive or easily discovered. There are oblique mention of workspace-scope variables in the documentation, but no real instructions on how to create them.

    Yes documentation is an issue. I apologize for this. We have a lot of work in the area of good documentation and it is a priority in 2013.

    John Enright said:
    Could we work some of these instructions into the "Portable Project" documentation? 

    Will do. The portable projects modules at the CCS training site needs to be updated. The slide I sent you on the ini files is new content, hence I sent it separately.

    Thanks

    ki

  • Ki-Soo Lee said:

    When moving the scope of the variable, I found that it's crucial that you remove the macros.ini or macros.initial from out of the project directory, or else the variable will appear at the project scope.

    where did you get your macros.* files from?

    [/quote]

    This used to be  CCSV4 project. So originally each person would:

    1. Check out the project files from the RCS
    2. Create an unversioned  macros.ini file, and place it in their working directory
    3. Import the project into the workspace (this would read the macros.ini)

    Now with CCSV5, the import process renames macros.ini to macros.initial. During the course of debugging this procedure, we had to go through a number of cycles of deleting the project (from the workspace) and then re-importing it. If the macros.ini or macros.initial file was in the project directory during the CCSV5 import, you would get a project-scope definition of the variable (and absolute paths in .project and .cproject), not a workspace-scope (which is what we needed).

    Thanks again for your help.

    John