Source Code Control Layout for LabVIEW Projects
I find that it helps to have a consistent folder structure for each project that makes it easy for someone unfamiliar with the project to navigate to the information they want
So you have downloaded the Viewpoint TSVN Toolkit and want to just dump your project in source code control (SCC) and keep on trucking, right? Wrong.
Now is the time to think about the folder structure in your SCC tool as well as your project and where your source code outputs will end up. We’ll assume you’re using Apache Subversion (SVN) because you downloaded the Viewpoint TSVN Toolkit, but these principles can be applied to most any SCC tool.
Repo Layout
You should create a new repository (repo) for each project, which may or may not contain several unique applications. I have seen some companies use one massive repo for all their code and it becomes incredibly difficult to manage.
Add an SVN tree (with a trunk, branches and tags) to the root of the repo or, if you have multiple applications in each project, the application folder in the repo. It’ll look something like this:
- Application A
- trunk
- branches
- tags
- Application B
- trunk
- branches
- tags
I recommend always creating these folders, even if you think you don’t need them. Adding this structure later is enough of a pain that you should just consider it a requirement and do it from the get-go. For now, everything will go into “trunk”. For more information on the SVN tree, have a look at the SVN documentation.
If you only have one application for this project, then just put the SVN tree right in the root of the repo. I personally use something slightly more complicated than this, but for now, let’s focus on the basics.
You can read more about how to use this structure here. I also recommend using Gitflow for larger projects and more experienced users to give you more control over releases and parallel development. Even though Gitflow was developed for use in Git, you can directly apply the principles to SVN.
Project Folders
Your repo trunk should be checked out to your projects folder on disk. The working copy folder name doesn’t have to match the name in the repo. Make sure to only check out “trunk” though, not anything higher or lower in the tree.
I find that it helps to have a consistent folder structure for each project that makes it easy for someone unfamiliar with the project to navigate to the information they want.
Here’s how each of these folders is intended to be used along with some additional, less-used ones.
Source
All source code that is used as part of the build of the project goes here. Notice the emphasis on source. If it is not source code (i.e. compiled code), then it should go in another folder, such as “Lib.”
Builds
This is probably the most controversial of these recommendations. Some people would vehemently disagree with me about putting build files in SCC. I’m ok with that. I have my reasons and I do set some limitations to this practice. First, I do this so that a developer (me included) can set up the project on another computer and be able to execute it without having to compile again.
Secondly, I do have my limits. I don’t put large installers or executables that are hundreds of MB in SCC. That situation does not happen very often though.
Test
Test is for code that you create for a project, but is not part of the build source. Any test VIs should go in test. For smaller projects, I usually throw out my file-naming scheme for this folder. That is part laziness, because it’s non-production code, and partly so it will be obvious to anyone looking at this folder that it is not production code and should not be considered part of the project source.
On larger projects where I write a lot of tests, I use more organization.
Docs
Only docs that you are creating for the project should go here. Reference materials should go in “Resource.”
Dependencies
All your VIPM packages, instrument driver installers, etc. should go in this folder. Any packages that the source code depends on to execute, that are not part of the source code itself, go here.
Lib
Any built libraries or assemblies from LabVIEW or any other language that the application calls can go here. Typically, you would never modify files in this folder. They contain purely compiled code.
Resource
This contains any reference materials (datasheets, manuals, etc.) that I need for a project. I also use this for non-code files that the project uses, such as images, icons, videos, and default configuration files. If you have some unique needs, like controlling the configuration files of several deployed devices, this would be a good place for that.
Utilities
These are utilities, created in LabVIEW or not, that aid in development or configuration of the development environment for a user. Some examples:
- VIs that create simulation data
- Build scripts
- Installers for tools that are critical for development, like an SQLite database viewer installer
Export
I use this folder when I need to do an intermediate export of source code to alter it in some way before building. You usually only need this when building more complex VI packages.
In summary, everything a developer needs to set up their environment should exist within SCC somewhere in this layout. There’s a place for everything, and everything in its place.
Now that you have your repository layout and project folder structure ready to go, keep an eye out for future blog posts around how you can improve the organization and naming of your projects.