Every Developer Needs a Time Machine

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:

1. You will be able to tell what changed from version to version
2. You will be able to go back to a previous version
3. 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