Version control - what to track and what not to

[dfjuggler]

I would like to use Git for LabVIEW version control and I can't seem to find a place with recommended practices regarding which files to track and which not. In the past (using Mercurial) I have version controlled every file, just in case, but this doesn't seem to be optimal.

Should one only track VI files? Should FPGA bitfiles be tracked too? What about auxiliary files like images and documentation (which could mean a Word document)? Built apps?

I have the impression that one commonly tracks source files only, but I then have the question of what should be done with binaries that need to be deployed and made available in some kind of repository for users to download whenever they want.

UPDATE: just found a post called The Essentials of File Management in LabVIEW which provides some suggestions.

[EricLM]

I think the answer is version control system agnostic. It depends more on what the files are.

You should ignore incidental files (like *.aliases and *.lvlps). These files are created and modified by the LabVIEW IDE and tend to get modified just by opening or saving a project on a different computer. The one exception is that if you are creating a custom .aliases files to be deployed with an exe.  In general, you should also ignore things like log files and test result files, if they happen to get written somewhere within your source structure. I actively try to avoid that, but sometimes inherit code that does this.

I also do not version control large output files (mainly installers). Some of the LabVIEW installers I create contain many drivers and software modules and can be hundreds of MB or more. I don't want that in SCC as long as I can easily recreate them. This also goes for very large installers for third-party tools (e.g. MySQL). In some of those cases though, you can get a web installer that is very small, but will at least dictate the correct version that should be used.

Aside from those things, I tend to version control all files; source, third-party drivers/utilities, build scripts, FPGA bitfiles, builds (exe, dll, rtexe, etc.). When another developer clones or checks out my repository, they should get a copy of all source as well as anything else they need to set up their environment to properly build and run the software. They should not have to search around for the correct tools; it should all be right there.

I currently use SVN, but when I occasionally use Git or Hg, none of these practices change.  There are many practices beyond this that help keep SCC sane, but this covers the "what" question pretty well.

[David_Staab]

Generally accepted by all software engineers:

• Anything generated by a build spec should not be tracked.
• Anything used as a source file for binary outputs (bitfile, application, DLL, installer) should be tracked.
• Anything automatically generated by tools as an intermediate output (e.g. source distributions that are picked up by another build spec) should not be tracked.

My additional guidelines for LV projects:

• Many source files are provided as development environment extensions through VIPM, so a VIPC of dependent packages is tracked in the repo.
• Most projects require drivers for hardware and instrumentation in order to compile them, so compressed installers for such things are tracked in the repo.
• Documentation of the code is tracked in a repo (a separate repo for a wiki, in our case). Documentation for anything other than code is not tracked.

[crossrulz]

Along the same lines as documentation, I have recently started putting requirement documents in my repository.  It is still early in my experiments, but it does seem to help keep everybody on the same page as far as what we have to do.