Skip to content

Instantly share code, notes, and snippets.

Last active March 8, 2018 12:39
Show Gist options
  • Save ahogen/93bf33ce47bb96c7fda60d844238fa43 to your computer and use it in GitHub Desktop.
Save ahogen/93bf33ce47bb96c7fda60d844238fa43 to your computer and use it in GitHub Desktop.
A tutorial describing how to keep code and Eclipse workspace metadata separate.

xTIMEcomposer Code Under Version Control


Do you need to keep your code under source/revision control with a solution like Git, Subversion (SVN), Mercurial? Are you using an Eclipse-based IDE like xTIMEcomposer (XMOS) or Code Composer Studio (Texas Instruments) and hate all the /.metadata junk that should stay far away from your precous code?

That's exactly what I wanted. I literally wanted just my code sitting under version control (SVN in my case) and I needed to be able to pull and build that code on multiple machines. Putting your entire workspace folder under version control is a really bad idea (I tried it) because it's got a bunch of junk created by Eclipse that you never wanted. It also isn't portable. Making a pull on a new machine results in a bunch of Eclipse errors.

This was my answer to my own question I posted/asked on the XMOS forums. The original post is here. I did have to compromize and leave the .project and .cproject files alongside the code, but I personally am fine with that.

Let's get started.


Starting with a full workspace of XMOS lib_* folders and my own project, I did the following...

  1. Clean the workspace to remove unnecessary files from the workspace
    1. Project > Clean
    2. Select "Clean all projects"
    3. Uncheck "Start build immediately", otherwise it will re-create the files we are trying to remove.
    4. Click "OK"
  2. Export all projects and libraries in workspace to my local (working copy) SVN dir
    1. File > Export > File System
    2. Select All
    3. Navigate to my SVN dir in "To directory"
    4. Choose "Create only selected directories"
    5. Finish
  3. Close xTIMEcomposer
  4. Manually copy and paste workspace folder somewhere temporary (just so you don't lose any code along the way)
  5. Make a new workspace (or simply empty out the old one if you like it's location on your computer)
  6. Open xTIMEcomposer
  7. If you changed the workspace location, do this. Otherwise skip these steps
    1. File > Switch Workspace > Other
    2. Navigate to the new workspace folder
    3. xTIMEcomposer will restart in the new workspace
  8. Link (but don't copy) projects and libraries from SVN dir into workspace
    1. File > Import > General > Existing Projects into Workspace
    2. Choose "Select root directory"
    3. Click "Browse" and navigate to the SVN dir where your projects and libraries were exported
    4. Click "Select All" to choose all projects and libraries
    5. Make sure "Copy projects into workspace" is not checked
    6. Finish


Now if you use your computer's normal file manager (Windows = File manager, Mac = "Finder", etc...) and navigate to the [new] workspace location, you should only see a /.metadata directory. There should be no projects or libraries. If I make changes to, say, main.xc, my SVN client will notice the changes, but none of the workspace-specific files (i.e. the whole /.metadata directory madness) are tracked.

On any new machine, after I checkout my SVN repo, (assuming a clean/empty workspace folder) I simply have to run through the Import operation (Step 8), being careful to make sure the "copy" option is unchecked, and I should be good to go. For any new libraries or projects I make, I can choose to create them inside the SVN dir, instead of the workspace. This results in the same behavior as above where the files are linked to but not inside of the workspace folder.

✅ No Eclipse settings
✅ No Eclipse addons
✅ Works across machines
✅ Happiness

Since this has nothing to do with SVN in particular, but rather the separation of my code from the workspace folder, this should work fine for Git, Mercurial, or whatever else you feel like using.

Hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment