Labview, Source Code Control and Backup

[FM82]

Good evening,

I'm am a developer in a small company that build Automatic Test Equipment (like most of you, I think). Most of the time I work on a project alone and sometimes my boss give me some VI to integrate in my code. We make no use of SCC and we do backup by copying the project folder on a server, manually!

Obviously this is a very bad, to say the least, way of working and I'm terrified of loosing code. So I was trying to convince my boss to adopt SCC as quicly as we can. 

I was wondering if someone can share with me the solution adopted to prevent code losses (backup) and the type of SCC implemented.

Thank you very much for your time,

Francesco 

[GerdW · Accepted solution]

Hi Francesco,

we use SVN.

As a help to convince your boss: SVN is for free, all you need is a computer acting as server from your IT department.

(You might even run the SVN server on a workplace computer, but then you are responsible for backups of that SVN server. When you use a server of your IT department then you can delegate the responsibility for those backups…)

[thols]

I am the only developer on my new job. I use Git. I couldn't live without SCC.

In short I did this to set up my environment:

- Install SourceTree. Set up a repository for each project (At first I had one repository for my reuse/generic code, but later I started using submodules for that, which you might wan to check out what they are from the start, but it worked for me to start using that later)
- Start working.
- Commit each change and comment on each commit. It will make the commit history useful.
- Tag releases. It will make it easier to see what code was released and easy to check out and perhaps branch on that code for making a bugfix on that specific release e.g.
- Backup the repository with a scheduled script (e.g. XCOPY)

Optional:
- Install TortoiseGit. I use TortoiseGit sometimes to do diff of VIs and to search log history. SourceTree does not work well for that with LabVIEW I think
- Set up Labview diff. Sometimes I want to see what changes I made. ToroiseGit+LVDiff works great for that. But forget setting up merge, it is a pain to use.
- Turn on "previous versions" in Windows on your working folder. Good for situations when you forgot to commit and delete files or when you accidentaly revert a file.

I am sure some googling will lead to more information of how it can be done, but this was a simple explanation to get you started.

[crossrulz]

Until the last month, I was using Tortoise SVN.  Very nice tool that works in the Windows Explorer window.  And it is simple to use.

However, due to some pressures from other departments and some discussions here, I have started porting my stuff to GIT, using Source Tree and an interprise GitHub.

[paul_cardinale]

In addition to SCC, you should setup your server to be robust.  We us Perforce, and our Perforce server was setup with a 4-disk RAID.  But during a power outage, all 4 disks were corrupted.  We eventually recovered all our data, but it was time consuming and expensive.  Naturally we've reconfigured our server.

[aputman]

This link was shared with me when I had the same question.  Fabiola shared some really good information on the topic, how to setup various types of source control.  I still haven't implemented any SCC solution but I also haven't done any development in a bit.  Good luck and keep the post updated with your experiences.  This question comes up a lot and it's always good to read people's responses. 

https://delacor.com/every-developer-needs-a-time-machine/

[Mark_Yedinak]

I use SVN along with TortoiseSVN. One thing that is EXTREMELY important when using SCC with LabVIEW is to separate the compiled code from the source. If you don't do this you will see lots of churn in your files even though they haven't really been modified. Change a typedef and every VI that uses it will be marked as modified because it recompiled. Mark all projects to separate the compiled from source as well as set it as a global option in LabVIEW. Also, always ignore the .lvlps and .alias files. These are auto-generated and will always be different on every computer. No need to put them into SCC.

[cbutcher]

I'm using Git for Windows mostly (although on this computer I use the Ubuntu shell in WSL) and the Git Bash shell.

I've set up lvdiff using the code available here: https://github.com/smithed/vicompare.

There's a tool there for lvmerge too, but I also don't use this - generally I make merges using a series of

git checkout --theirs blah/my/directory/fileA.vi
git checkout --ours blah/my/directory/fileA.vi

or

git diff :{0,2}:blah/my/directory/fileA.vi

The 0 and 2 are the indices of code from the different branches, I can't remember which numbers mean what so sometimes I have to try a few combinations, 0-3 are valid but usually not all are defined depending on the reason for conflict.

Edit: see spoiler for details

Spoiler

Copied from https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltngtltpathgtemegem0READMEe..., which also has a diagram

:[<n>:]<path>, e.g. :0:README, :README

A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path, names a blob object in the index at the given path. A missing stage number (and the colon that follows it) names a stage 0 entry. During a merge, stage 1 is the common ancestor, stage 2 is the target branch’s version (typically the current branch), and stage 3 is the version from the branch which is being merged.

Like Mark said above, it's crucial that you remove compiled code from source, and it's wise to add *.lvlps and *.aliases to your .gitignore if you use git.

[BertMcMahan]

Another vote here for TortoiseSVN with an SVN server running on the main company server. When I have to go offsite AND don't have access to the server, I have a NAS with SVN running on it.

[billko]

Beyond simply giving you a lifeline should something disastrous happen to your computer or code, it gives you freedom.  You can strike out in an entirely new and unknown direction and know that, if it ends up a dead end, you can just go back to where you branched and continue from there.  And, short of physically destroying the database by deleting it, or deliberately corrupting the database, every commit anyone has ever done will be available to you; there's no way you can "lose" something.  You may cause the admin headaches and may tell you never, ever to do that again, but anything is recoverable.  (But the working files are vulnerable to being lost.  Imagine making changes, then reverting them to the last revision.  Those files you changed, then reverted, cannot be recovered!)