• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 1837 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.

How to put CC26xx project under version control git/svn?

Christian Ege
Prodigy 60 points

I am planning to build a project based on the SensorTag 2.0. After checking all those example Projects I am wondering how to put this whole stuff under Version control?

Under CCS virtual  folders are used  anywhere.  It looks like the only solution is to put the whole C:/ti/... Folder under source control system.

Which is not a good idea. Think about various project you are working all of them modifying a common code base.     

  • 0
    Prodigy 45 points
    +1, some howto for how to put those CCS projects under version control would be good. I wonder how development in a corporate environment is done where everything has to be repeatably built.
  • 0 in reply to Daniel Schnell
    TI__Guru** 105180 points

    Hi,

    The recommendation would be to place the entire SDK under version control. I'm not sure why this is viewed as not a good idea? Of course, you can place specific sections under rev control - it's personal choice.

    Attached is an example .gitignore file.

    Best wisheshttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/.gitignore

  • 0 in reply to JXS
    Prodigy 60 points

    Hi,

    This is a very pragmatic approach :)

    • But what happens in case of an upgrade of the installed files? This may cause trouble for version control systems like SVN where ".svn" is put everywhere. 
    • What to do If I work on multiple Projects and all of them need modifications in a common place? Should I use different branches for each of them?
    • What is the preferred way of using this? Checkout is better than installation of the tools? Or should I install the whole bunch and checkout everything to this location?
    • What is about Buildservers like Jenkins? Normally they have permissions to checkout their data to a particular location and not to a system wide path. "C:\ti\...." So I have to hand-tune the project files?

    From my software developer point of view this feels like a hack. 

  • 0 in reply to Christian Ege
    TI__Guru** 105180 points
    Hi,

    My *advice* is to use a more modern rev control tool, like GIT. The choice is yours though, and the system/implementation should be based on your particular environment.

    Perhaps others in the community with a strong CM background can share their wisdom, but you may find more advice on a dedicated GIT (or similar) forum. All I can add is the BLE Stack SDK does build fine under SVN and GIT.

    Best wishes
  • 0 in reply to Christian Ege
    TI__Mastermind 29650 points

    An optional way to do this is to use a relative path (supported in IAR >=7.30.1 as custom argument variables) and make all application project files, compiler search paths, linker libraries etc relative to the install path. This way you can take your project (including application source) and pull out of the installation folder.

    It is however a labour-intensive and error-prone job to do this and in many cases not worth it as the functionality in the BLE installation application components (such as Profiles, bleUserConfig, GAP callbacks etc) needs changes. If search paths etc are changed in future releases this complicates things even more.

    What also can create issues are the tools we have added to the projects:

    libSearch  - parses the stack configuration file and copies the correct stack library

    Boundary - parses the stack & app map files, adjusts the RAM/Flash boudary between the images for maximum size to the application.

    Our way of doing it is to put the full -clean- BLE installation under version control using the example .gitignore file. This does not need to be c:\ti but could just as well be e.g. c:\users\jenkins\.

    Christian Ege said:
    • But what happens in case of an upgrade of the installed files? This may cause trouble for version control systems like SVN where ".svn" is put everywhere. 

    The .svn folders would anyway not be overwritten by a new BLE installation so I don't see that as being an issue.

    Christian Ege said:

    Hi,

    This is a very pragmatic approach :)

    • What to do If I work on multiple Projects and all of them need modifications in a common place? Should I use different branches for each of them?

    With Git I would keep a "common" branch up to date and either merge this into your project branches or cherry-pick the needed commit.

    Christian Ege said:
    What is the preferred way of using this? Checkout is better than installation of the tools? Or should I install the whole bunch and checkout everything to this location?

    We install once when creating the repo and then check out on all other setups later.

    Christian Ege said:
    What is about Buildservers like Jenkins? Normally they have permissions to checkout their data to a particular location and not to a system wide path. "C:\ti\...." So I have to hand-tune the project files?

    For IAR, all you should need to do is modify the paths in the custom_argvars file included with each project. CCS also have variable-based project setup for install paths.

    There are challenges with most approaches here but we would be happy to receive feedback on any solutions you find for this as this is a challenge affecting most SW devs working with our BLE SW.

    Best regards,
    Svend

  • 0 in reply to svendbt
    Prodigy 45 points
    Ok, same discussion put a bit further:
    what do you propose to put under version control if one wants to publish a part of a BLE project for CC26XX on github? How is that supposed to be done?
    I'd think that many parts of the BLE stack are _not_ under an unrestrictive license, so putting the complete BLE stack on github is probably the wrong solution. Could maybe git externals help here ?
  • 0 in reply to Daniel Schnell
    TI__Mastermind 29650 points
    Daniel,

    Much of our BLE stack has a license that allows usage and distribution only when used in conjunction with our radio micro controllers. I am not sure how that will work wrt open sourcing code samples including the stack on e.g. Github.

    What you at least can do is to upload any of your own samples to Github and use path variables to the installation path. This will make it possible for others to easily reproduce the project by downloading the same stack version as you used and compile with this.

    Regards,
    Svend