MQX and Code Warrior 10 (Eclipse) Version Control - what files to version?

[dhlocker]

If this knowledge is available by Reading The Fine Manuals, I'd appreciate a pointer to TFM. So far, my Google searches haven't turned up anything terribly useful. I'm now reading the help.eclipse.org pages, but it might take me a while. Eclipse generates an awful lot of scratch/state files as it operates, and Code Warrior adds its own set of complications. I'm trying to find what files to keep in version control (Mercurial, for what it's worth) so that my compatriots and I can share MQX build configurations and source base files without versioning all the log, lock, index, pdom, prefs, ... files. So far, I have not found a set of files that allows others to restore a workspace from a versioned archive and build the MQX libraries successfully. Is there a set of files that can always be ignored (*.pdom, *.d, *.args, *.obj, ) and a set of files that are always required? (.cproject, .project, [0-9]+.tree, *.[csh], others?) What about *.snap and *.index? Are they valid on any other machine than the one on which they were generated? .metadata/.plugins/..../.location has machine-specific information in it. Can its contents be "fixed" to use one of the _LOC or _PATH variables so as to be portable? Regards, Donald.

[DavidinKY]

 I, too, would like to know what CodeWarrior files can be eliminated from version control. Any answers?

[dhlocker · Accepted solution]

I've been getting my process under control and have the following recommendations to make.  I reserve the right to change my mind at any time, though.  For now, these are working.  This works for me for CW10; YMMV, NFI, OIMACTTA, ...

0. Nothing in the .metadata directory is versioned.  In fact, I've taken to tossing .metadata occasionally when CW gets its knickers in a twist - it's faster to rebuild the .metadata (couple of hours) than wrestle with a confused CodeWorrier.

1.  No derived files are versioned (*.args; *.d; subdir.mk; makefile; *.elf; there are probably others, but these are the biggies.)

2.  All source directories are versioned.  Depending on the organisation, there may be one or multiple repositories associated with each top-level source directory.  Generally, library source is versioned separately from demo or example sources.  Different elements of the library sources may be versioned separately from others.

3.  In the build directories, .cproject and .project files are versioned, as are .*\.launch files.  The .ttf files don't seem to be recognised, but I've been versioning them.  Target Task Framework has never found or recognised one of my local .ttf files, so I mostly ignore them after committing them the first time.

4.  I am using the Mercurial Eclipse plugin from <http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable> and have no complaints about its performance or integration.  It does show that .cproject and .project are somewhat dynamic, with lines moved up and down, whitespace added and deleted (likely by the last tool touching the file) and that is a right nuisance, but the tool itself is good.