Opinions on keeping compiled files (exe's, lvlibp, etc) in version control?

[BertMcMahan]

Basically the title. How do you guys manage your compiled outputs? Do you keep them in your version control software? A separate network location? How do you "connect" your builds to your source?

I've tried a couple different ways and so far haven't found anything I really like. I'm using SVN, for what it's worth.

[santo_13]

One of the best practices is to maintain the builds/releases parallel to the source folder on SCC and configure the build output folder to utilize the version number in the folder name.

This way you have a single location to get all the historical builds.

[Jay14159265]

It is nice to have your compiled code in the repo for tracking but it takes up a lot of space. I used to use SVN and the pristine files got to be untenable, like 10GB for a project. So I had to keep the compiled versions elsewhere, even then, the pristine files would sometimes be very large for LabView projects.  

I switched to GIT and after some trial and error found that a very reasonable way to track code is to use GIT for the source code and GIT LFS (Large File Storage) for the compiled release files, that way they are all linked by the same version control. Disclaimer I pay for bitbucket to host my GIT repos (and after using jira for a few years, I don't know what I would do without it).

https://support.atlassian.com/bitbucket-cloud/docs/use-git-lfs-with-bitbucket/

You can set the pattern to match '.exe' or a path and the large files will be tracked by version control but not directly stored in your repo. This way you can have a release branch that tracks you source code and the release files together, so it is a nice solution. 

[Bob_Schor]

I also use SVN.  I don't keep executables in SVN.  When I'm doing FPGA code that is specific to my Project, the BitFiles are not included (and require a separate Build step each time I update the FPGA, but that's needed, anyway ...).  Things that I put in "common Libraries" (managed by VIPM, for example), have their own repository for the Sources, and typically don't (or rarely) change, except, perhaps, when I install a new Version of LabVIEW (and rebuild the Library).

Bob Schor

[Terry_ALE]

We store most builds in source code control.

Releases to customer are always stored.

If we run out of room, we make new repositories and may break the project up even further.

[Mark_Yedinak]

I also use SVN. I don't keep anything that can be rebuilt in the repository. I also tag the repository after every build so I can go back to the code if needed. I simply check out the tagged version if needed. If you expect you will need to maintain multiple projects then I would suggest using branches.

[Hooovahh]

There are certainly reasons why you might want to include builds in SCC.  One thing I can think of is the fact that if you generate a LabVIEW EXE, then generate another one without changing anything, the two generated files won't be the same bit for bit.  I'm not sure if this comes down to compiler optimizations having some weird entropy or if it is as simple as the date time is in the file somewhere.

But my point is, if someone comes back years later and asks you to investigate some behavior in an EXE, you might not be able to know exactly what version it was from.  Sure the EXE can have a build number of 4.2.1, but were there multiple EXEs with that build number?  There shouldn't be but it can happen.  Having the binary from the release, in SCC means you can have the exact EXE in SCC, and you can know what commit went into that build.

I don't think it is a good idea to put installers in SCC because of the number of files and size.  But even then you could say that the installer may include a different version of DAQmx in the installer, depending on what is on the development machine.  You probably should have a locked down development machine, but I'm often working on many projects at once, and having a separate VM for each becomes a difficult.  I do have a couple for the larger and important ones.

Okay I'm going off into the weeds.  Basically I recommend not having the installers in SCC, and while I don't currently have EXEs in SCC I see a reason you might want to.  I do put FPGA binaries into SCC, because building them can take a long time, but they could be stored separately.  I do put VIPM packages in SCC, but I think a separate released location might be better, like the installer.  Packed Project Libraries is another one that it might be a good idea in SCC but I don't make those at the moment.  I do put RT builds in SCC like FPGA builds, but again I'm thinking it doesn't need to be.

[rwunderl]

We typically keep the EXE builds as part of the tracked repository, but separate the Installer builds (as they are huge). The Installers can be burned to a CD or DVD for physical archiving if the SQA program requires it or just copied to a server for historical purposes. Since the EXE files are typically under 10 MB, keeping them in the repo isn’t very taxing on the repository size versus the hundreds of VI files that are also binary and can’t be efficiently text-diff’d.

We mainly use Mercurial (distributed version control) for tracking changes. We upgrade LabVIEW versions every 3 years or so when it is convenient for the project. When we upgrade, we duplicate the project to a new development folder (by LabVIEW version), remove the old repository from the copy, and begin a new repository with a commit of the binary equal to the last commit of the previous repository (got all that?). Then you can recompile and commit and move on from there.

In this way we maintain traceability between the LabVIEW versions of the same application without keeping all that bulk for years and years. This generally keeps the repos from growing beyond 1 GB except for the largest of our projects. Typically, a repo might hover around 100-300 MB for several hundred commits.