For more information, check out the official announcement on the JKI Software Blog.

So, how do you deal with all the unsaved VIs in your project that are not in an area that you “own”?  If you don’t save them, then LabVIEW will keep bugging you to save the VIs.  And, sometimes your LabVIEW code will even run slower until you save all your VIs.  But, if you do save these VIs, then it’s hard to tell which VIs that you’ve saved have “real” changes and not just recompile changes.  And, if you commit all the changed VIs, then you might increase the likelihood of creating a conflict with other developers.

Here’s a good process you can follow to deal with this issue:

1. First, commit your real changes, separate from the recompile changes.  This will give you a specific svn revision (changeset) associated with your real changes.
2. Then, save all the recompiled VIs and commit them.  For your commit log message, use “Recompiled due to typedef changes” (or similar).  This will indicate to other developers that the changes can be ignored, in the event that this revision conflicts with their own changes.
3. Finally, Alert your team that you have committed a recompile of code (with no real changes).  They can then easily resolve any conflicts, because they know that the commit contains no real changes.

Now, if you know that other team members are actively working on the code and you don’t want to inconvenience them with having to deal with conflicts, you can defer the recompile until a later time or schedule a time for the recompile with your team.

Note: Even if you use a locking system (such as svn locks or a check-in/check-out SCC model) where files for which you don’t have the lock are read-only, you will still have the slow-down issue and will periodically want to do save all to recompile.

Have you had this issue?  What solution or process do you use?

The svn:externals feature allows you to create a working copy consisting of multiple working copies from several repositories (or several locations within the same repository).  Basically, it allows you to create something like a “symbolic link” (or “shortcut” in Windows).  The end result is that a sub-folder in your working copy is actually in a different repository (or repository location) than it’s parent folder — you’ve effectively “mounted” a different repository location as the sub-folder in your working copy.

The way that you do this is to set the “svn:externals” property in the parent folder.  This tells the Subversion client (such as TortoiseSVN) to treat the sub-folder as part of the working copy.

This is a very powerful feature that allows several projects to reuse common code.  That sounds great, but there’s a big problem:

When you create a tag in subversion (such as when you create a release of your product), you’re not tagging the svn:externals repository — you’re tagging your working copy, which references the svn:externals repository.

So, if your svn:externals property does not specify the revision of the svn:externals repository, it will always float to the latest version when you do an update, including when you checkout or do updates on working copies of tags!  In other words:

If you do a checkout of a tag, any svn:external sub-folders (without revision information) will update to the latest revision and not the latest revision at the time you created the tag!  This means that you probably don’t have an exact copy of the code that you tagged.

The solution is to explicitly set the revision of the svn:externals property.  For example, instead of setting the property as the following:

toolkit http://svn.red-bean.com/repos/skin-maker

We should explicitly set the revision, like the following (note the “-r 21″ argument):

toolkit -r 21 http://svn.red-bean.com/repos/skin-maker

Allowing an svn:external to float to the latest revision may be is desirable for working in the trunk (when we’re working towards a release), however this is certainly not desirable in a tag (when we want a permanent record of what we released).  There is really only one correct way to address this issue (that I can think of):

Make sure that your trunk specifies the revision of svn:externals before you create a tag.  You can always unset the svn:externals revision in the trunk, after you create the tag.

Now, you might want to let svn:externals float to the latest revision when you’re doing development on the trunk, but this requires that you are diligent about setting the revision of svn:externals, before you create your tag.  This is manual work (unless you have a script that does it for you) and might not get done by lazy developers (and we’re all a little lazy, aren’t we?).

How do we fix this problem, if we’ve have already created a tag that doesn’t specify svn:externals revisions?  Easy: you can go into the tag and look at the log to determine the svn:externals revision at the time the tag was created.  Then, set the svn:externals revision in the tag.  However, this is considered “cheating”, since you’re not really supposed to commit changes to tags — that’s what branches are for.  However, it’s a necessary fix for a bad tag.

On a side note, I wonder why TortoiseSVN or the command-line svn client don’t have a feature to automatically set the revisions of svn:externals during a tag operation — and, at least they could warn you if you try to create a tag that has svn:externals that don’t have revisions set.

I figured that I would re-present the information here, for LabVIEW users, but try to simplify the instructions, a little bit.

To do this trick, you basically export the working copy onto itself — meaning, you choose the working copy’s location as your checkout destination (so that the export source and destination are the same).  TortoiseSVN is smart about this and realizes what your trying to do, and it simply removes all the .svn folders from your working copy.

You can do this trick, one of two ways:

Method 1) Right click on your working copy and choose TortoiseSVN>>Export.  In the resulting file dialog, browse to the working copy folder, select it, and choose OK.

Method 2) You can use the TortoiseSVN Right-Click Drag and Drop feature, using the technique shown in the screenshot below.  First, make sure to select “Folders” to view the explorer tree.  Second, use the File Explorer tree to select the working copy’s parent folder in the tree (Folders area to the left), so that the working copy folder is visible in tree and in the file list (area on the right).  Third, right-click drag & drop your working copy from the file list (on the right) onto itself in the tree (on the left).  Then, when the pop-up list of choices appears choose “SVN Export versioned items here”.

Method 1 is a little bit harder, IMO, since the file dialog is one of those awful Browse for Folder (explorer) dialogs (which I don’t like), instead of a standard File Dialog that you can use to paste in a path (which I prefer).  But, Method 2 is trickier to understand, but hopefully the annotated screenshot, above, helps.

Do you know any other useful TortoiseSVN tips?  Please leave a comment and share them.

When jumping head first into a new LabVIEW version there are bound to be some unknowns.  In my case, I noticed that, after saving my project (.lvproj) file, an .lvlps file showed up in my project folder (right next to the .lvproj file).

What's that new .lvlps file?

So, I opened up the .lvlps file in a text editor and saw that it contained the following:

[ProjectWindow_Data]
ProjectExplorer.ClassicPosition[String] = “59,221,459,571″

It appeared to store some window settings for my project.

Figuring there’s probably something in the LabVIEW help about this file, I search the LabVIEW help for “lvlps” and found the “LabVIEW File Extensions” help page.

.lvlps

File that stores project settings that are specific to the local machine. You should not check .lvlps files into source control because .lvlps files contain settings specific to the computer you are using; for example, .lvlps files contain the local source code control configuration. LabVIEW saves .lvlps files when you save a project, and correctly renames the file when you rename a project. You can remove or delete .lvlps files without affecting the performance or behavior of a project because .lvlps files only contain project settings specific to the local machine. If you build an application, LabVIEW does not copy the .lvlps file into the built application.

Conclusion: OK, the .lvlps file contains my LabVIEW Local Project Settings.  So, I don’t want to check it into Source Code Control, because each developer working on the project will probably have different settings and they aren’t really important enough to do change control.

Note: I kind of like how Apple Xcode project files (actually they are “package” folders — they just look like files, in the Finder) work.  Your local Xcode project settings (like window positions) are stored in files that include the user’s name, so that you can, if you want, save them in source code control without developers overwriting each others’ settings.  But, since Windows doesn’t really have a feature like “packages” (and LabVIEW needs to be multi-platform), I guess we’ll have to keep doing things the hard way.

And, did you know that there is a great tool called Beyond Compare that (among many other things) can compare the differences between ZIP files? Beyond Compare can look inside of ZIP archives as if they were real folders on your hard disk, allowing you to see the differences of files inside the ZIP archive.

To see this in action, let’s configure TortoiseSVN to use Beyond Compare as the Diff tool for *.zip file types. It’s really easy. First, launch the TortoiseSVN Settings dialog (shown below) by right-clicking on a file or folder and choosing TortoiseSVN>>Settings. On the Diff Viewer page [1], press the Advanced button [2] to open the Advanced diff settings dialog. Then press the Add button [3] and enter “.zip” as the Extension and the path to Beyond Compare (BC2.exe) as the External Program [4].

Now, let’s show the differences of a modified ZIP archive (“My Archive.zip”, in this case) that is in a TortoiseSVN working copy. Note that Beyond Compare is launched and we can not only see what has changed in our zip file, we can actually compare the differences of the individual files inside the ZIP file (as shown below).

Note that many other source code control tools (besides TortoiseSVN) allow you to specify external applications for comparing differences of specific file types. Check with your source code control tool’s documentation for more details.

And finally, if you’re not using Beyond Compare, you should definitely take it for a test drive — it’s got a lot of great features

Here is a short list of the top 5 bad excuses for not using source code control (and the reality behind why these excuses shouldn’t be holding you back):

1) I’m just one person, so I don’t need source code control.

Reality: Single developers make mistakes all the time. And, they can easily benefit from being able to restore from any revision of their sources and to see a descriptive log of changes. Also, source control tools make development on more than one computer easy (consider your office computer, laptop, and those few lab computers).

2) Source code control tools are expensive and I can’t afford them.

Reality: There are great free tools. For example, subversion (and the TortoiseSVN client), CVS (and the TortoiseCVS client) are free. Also, Perforce, a commercial product, has a free version that limits the number of user accounts.

3) I don’t have a server computer or any IT support (or desire to have them support me).

Reality: With TortoiseSVN (and others) you can create a “local repository” on your hard drive, so you don’t even need a server. Give it a try — it’s easy.

4) I already have a simple folder backup/archiving scheme in place.

Reality: Once you start using a version control tool you will realize that it basically does exactly what your folder archiving scheme does, but also does a lot more and a better job of it. Your folder backup scheme is prone to human error. And, trying to figure out differences between versions is pretty complicated, too. Also, how do you backup your folder backups/archive? With a source code control system you have a single central repository that can be backed up. (Note: if you are committed to using a folder backup scheme you should definitely take a look at Beyond Compare for comparing folders and files.)

5) I don’t understand the concepts of source code control.

Reality: Learning these concepts is important. You’re already doing these activities, you just don’t realize it and your probably not doing a great job at it. If you’d like to learn more about the concepts of source code control, then you should definitely read Eric Sink’s Source Control HOWTO.

Also, TortoiseSVN is easy to use — it integrates directly into Windows Explorer. You simply right-click on your files/folders to perform operations. And, your files/folders icons change to reflect their state in the source code control system (modified, not under version control, etc.).

Apples and oranges photo courtesy of Dano.