This post was originally published at Walking the Wires
I gave a presentation at NIWeek 2013 that turned out to be a lot more successful than I ever imagined. I was interviewed by VIshots, I was asked to give the same presentation at NI Days in Paris and my friend Steve Watts gave his own version at NI Days in London the same year. Steve also did his own blog post. The title was “How to Polish your software and development process to wow your end users“. There were 5 tips in there, with some more focused on the UX (Usability Experience) and others focused on DX (Developer Experience). Today I want to focus on the last point from that presentation: “Every Developer Needs a Time Machine”.
Let’s start with a cartoon based on a real story that happened to me when working with a third party software provider:
Here is a video of the presentation starting at the moment I was talking about Source Code Control:
I have to thank Steve Watts for that last line: “Good programming practices have nothing to do with marital status”. If you watch the video you will hear how a fellow at the front row laughed so hard that I knew I stroke a chord with that one. Over the years, I have asked how many LabVIEW developers were using Source Code Control at the beginning of several of my presentations. I am happy to report that the number has been steadily growing and now people approach me asking more about how to do it rather than why to do it. I no longer hear the “but I work by myself” argument. Even my poor husband has started to use SCC. A couple of months ago he asked me to help him recover a LabVIEW project that was corrupt. I told him, well just go and update to the previous version you committed and you should be good. He did not want to tell me, but he finally did: “well, I was not using SCC, because it was a small project… “, I then asked him how long he had been working on this small project, the reply: more than 6 hours. I don’t know about you, but I don’t want to lose 6 hours of my life. Anyway, after being mean for just a little bit I did help him to recover his project employing some XML magic. He assures me that now he starts a repository no matter how small the project is. If it is going to take him more than an hour of his time, it gets a repo created.
So why am I so passionate about Source Code Control? Well, it has saved me time, money and I just cannot imagine my professional live without it. It is almost as good as ice cream, cheese or chocolate. Yes, it is that good!
Source Code Control and the path to happiness:
- You will be able to tell what changed from version to version
- You will be able to go back to a previous version
- You will not lose your code due to an alien invasion that targets your hard disk and makes it explode…. (that is of course provided that you do have a repository/backup offsite and that you make sure that you backup your repositories often).
The LabVIEW community mainly uses Subversion with the TortoiseSVN client and the LabVIEW Tools Network addon from Viewpoint systems. SVN is even taught during the Managing Software Engineering in LabVIEW class and there are exercises in the Software Engineering Technical Manual. I recommend this SCC tool for single developers. Subversion is a centralized source code control tool, which means all the developers commit their changes to that central version of the code. One of the drawbacks I see is that team members tend to withhold committing changes because they don’t want to commit broken code. This ends with team members not committing often enough.
SVN setup for LabVIEW:
SVN setup video timeline:
- 00:00 Download TortoiseSVN
- 00:51 Getting Viewpoint Systems SVN Toolkit
- 01:24 Letting toolkit configure LVCompare and LVMerge
- 02:09 How LabVIEW compare gets configured (note -nobdcom = no block diagram compare and -nobdpos = no block diagram position changes, more attributes can be found here)
- 04:07 Create SVN repository in a mapped network drive
- 06:20 Import existing code into Repository
- 07:32 Checking out code from repository
- 08:50 Removing .aliases from SCC
- 09:10 Separating Source Code from Compiled code
- 10:10 First commit
- 10:12 Removing .lvlps from SCC
- 11:19 Bring another team member to use SVN (white computer)
- 12:12 Check out code to other computer (white computer)
- 13:30 SVN Commit directly from project
- 14:47 Use toolkit to check for modifications before updating
- 17:04 Using SVN to go back in time
- 19:23 Diff with previous
- 20:34 Conflict resolution
At Delacor we specialize in working with teams of LabVIEW developers who want help on implementing good software engineering practices. When working with teams I prefer to recommend a distributed source code control tool. Personally I prefer Mercurial (Hg) in combination with TortoiseHg as a client. However, Git has been getting a lot more traction in the rest of the software community and there are a lot more tools for it. So for those teams that need to work with other non LabVIEW developers, we recommend Git with SourceTree as their client tool. SourceTree can also be used for SVN and Hg, but I find TortoiseSVN and TortoiseHg easier to teach to people. The main drawback I see with these tools is the learning curve, but believe me, once people get over the first obstacles they will not think about going back to SVN.
Hg setup for LabVIEW
Hg setup video timeline:
- 00:00 Download TortoiseHg
- 00:50 Using Bitbucket to create repository
- 01:22 Clone repository
- 04:17 Getting existing code into repository
- 04:35 Editing TortoiseHg settings
- 05:19 First commit
- 06:33 Remove .aliases and .lvlps from SCC
- 07:45 Separating Source Code from Compiled code
- 08:58 First push
- 10:55 Bring another team member to use Hg (white computer)
- 13:43 Commit (note that TortoiseHg workbench shows “draft” instead of “public” at the top of the tree)
- 14:45 Push (note that after the push is complete version 4 shows “public” instead of “draft”)
- 15:17 Pull into blue computer
- 15:30 Update
- 17:18 Commit on blue computer
- 18:20 Commit on white computer
- 19:30 Undo, go back in time
- 20:18 Push from white computer
- 21:13 Pull on blue computer
- 22:26 Additional minor change on blue computer before merging with changes from white computer (note this is not possible in SVN, the developer in blue computer is forced to deal with conflicts right after they update and could not continue to commit and work on parallel until that is done).
- 23:17 Conflict resolution
- 25:11 Push on blue computer
- 25:37 Pull on white computer
- 27:00 Simulate loosing internet connection
Git setup for LabVIEW:
Git setup video timeline:
- 00:00 Download and setup SourceTree
- 01:30 Using Bitbucket to create repository
- 01:48 Clone repository
- 03:52 Getting existing code into repository
- 04:00 Remove .aliases and .lvlps from SCC
- 04:23 First commit
- 05:17 First push
- 06:29 Second commit (showing that it can be configured to push immediately after the commit)
- 07:30 Push
- 07:44 Bring another team member to use Git (white computer)
- 09:27 Commit on white computer
- 10:44 Commit on blue computer
- 11:51 Push on white computer
- 13:00 Push on blue computer
- 13:56 Push on white computer
- 14:43 Pull on blue computer
- 15:10 Undo, go back in time
Distributed Source code control means that every team member has a complete copy of the repository, including all its history. This means that each team member has a backup of the repository. However, this is no excuse to not making backups of your repos.
The videos embedded above can be found in the following playlist. We might be adding more scc related videos there:
http://bit.ly/LVscc
If you are already using source code control for your LabVIEW projects, good for you! If not, I hope I have already convinced you. If not, please let me know in the comments what is stopping you, I promise I will not go LabVIEWzilla on you 😉
Happy wiring!
Fab
Hi Fab,
you mentioned in the ‘Hg setup for LabVIEW’ video being able to save the password. Do you do this using the ‘Keyring’ extension to Tortoise Hg? Do you have an example of what I need to do?
Thanks
Al
Hi Alastair,
I use Puttygen and Pageant. I have in my to-do list to create a video for this. In the mean time you can check out the following:
Setup SSH for Mercurial (same process for Git):
https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html
Setting up Puttygen keys:
Making Pageant automatically load keys:
http://blog.shvetsov.com/2010/03/making-pageant-automatically-load-keys.html
Manage startup items in windows 8 (so Pageant starts automatically):
http://www.eightforums.com/tutorials/5180-startup-items-manage-windows-8-a.html
Regards,
Fab
Thanks, working perfectl
Al
Hi Fab,
I’m being an SVN user so far, I got used to SVN-lock mechanism for preventing other developer to disturb my code. Else, in LV environment it would be very difficult to merge the VIs modified by multiple developer. How do you handle such situation in Git? Due to distributed source control and each developer has their own repo, there are more chances developers will work in same VIs and need of more merge actions in LV.
Thanks,
Ajay
Hi Ajay,
What we have done at Delacor and with our customers, is to first review the overall architecture. A more modular architecture means that rarely developers need to work on the same VIs. They might be working on the same library, class or project, but rarely on the same VIs.
If you are having to deal often with multiple developers working on the same VI, this is an architecture smell and needs to be reviewed.
Merge within LabVIEW doesn’t work well, unless we are talking about small changes like the ones I show in the SVN setup video. Above all, I recommend avoiding it. I will still add to my list of to-do articles/videos to do one on how to setup Merge when using distributed Source Code Control.
In the mean time, check out this ni.com forum post that has some good tips on how to setup Merge when using TortoiseGit: http://forums.ni.com/t5/LabVIEW/LabVIEW-and-git/m-p/3369787#M992140
Thanks for reading,
Fab
Hi Fab,
Are there any notes how to setup the LV diff tool for TortoiseHg?
Thanks
Hi Milinda,
Not yet, I will be posting about it soon. I prepared a session called “Merging and Comparing LabVIEW Code with Git or Hg” for National Instruments Developers Days (http://www.ni.com/en-us/events.html). The videos for the demos are up, but they have no sound. If you want to check them out, they are at: https://www.youtube.com/playlist?list=PLZ3A_SIOKdQvdJ9W31h6a8iY3lCxjW4TH Unfortunatelly, only LVMerge can be configured for Mercurial. You can still compare two VIs as part of a merge and just not go through with the merge. Another alternative is to update to the older version, make a copy of the VI, update to the newer version and manually call the Tools>>Compare>>Compare VIs…
Milinda,
The post with how to setup LV diff tool for Git and Hg is up at: http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge/
Regards,
Fab
Thanks for putting together such a useful and detailed set of guides, this has been very helpful. I noticed in the examples that you always close the LabVIEW project before any git operation. It makes sense to me that you would not want to pull or merge with your project open because LabVIEW already has some VIs loaded into memory. But is it possible to commit changes without closing the project each time if you save first? Is this something that can cause problems if you forget to close the project before performing git operations?
Hi Brian,
This is one of those compulsive things I do, like saving very often. As you point out, it is not needed to close the project before committing, doing a save is all you need.
Glad you found the guides useful.
Regards,
Fab
How do I merge the project file? I have two users creating DQMH modules and events in the same project. When we commit to svn we don’t see the new modules and testers the other person has created. This is because we only can sync our checkouts once a week working in an air gapped network environment with only weekly commits. Can lv project files be diff’ed and merged?