Have you been thinking of moving to subversion to manage your source code but don’t want to set up your own subversion server. Subversion has become a de facto standard among LabVIEW developers around the world as a source code control solution. Weather you are a lonely developer or leading a large group of developers, source code control hosting service might be the best solution for you. Using a managed subversion hosting service is cheap, and you don’t have to consume your valuable time in setting up and maintaining the subversion server.

There are several subversion hosting services out there. I’ve been using for the source code of my personal LabVIEW projects and other software projects service provider called ProjectLocker. For merely $2.50 a month ProjectLocker provides a managed subversion service for my projects as well as Trac issue management tool. This cheapest ProjectLocker service package is suitable for personal development projects but they also have bigger packages for larger groups. The price per user for all packages ranges from $1-$2,50 per month, which is hardly nothing compared to the value of having a managed source code control service together with an issue management service. ProjectLocker promised to offer ExpressionFlow readers the first 30 days free on a subscription to any of their services by entering “LABVIEW” in the Promotional Code field at signup.

If you have been hosting your personal subversion repository on your local hard drive, you should consider hosted subversion service. With local repository you are tied to a single computer. Hosted subversion service allows you to work from anywhere and from any computer on your projects. If your company is hosting its own subversion server, external subversion hosting could be a cost-effective and easy alternative. If you or your work group is not yet using source code control, you should no longer have any excuses. Source code control is a must have tool in professional LabVIEW development and using a subversion hosting service makes the first steps very easy.

Don’t forget our earlier article Using new LabVIEW Merge Tool LVMerge With TortoiseSVN. Also check ThinkingInG subversion resources.

EDIT: I found a comparison chart on subversion hosting providers. Don’t read the chart literally, as most providers do have multiple products and not all products are listed. Rather take it as a list of subversion hosting providers aand check yourself what kind of solutions they provide. Not that many subversion hosting companies provide services for open source projects only.

I started to write this article in June 2007 and a recent post on LAVA made me realize that it may still be of use

National Instruments (NI) has provided LabVIEW developers native OOP support (LVOOP) since LabVIEW 8.2. Users of LVOOP can quickly build single inheritance ByValue object hierarchies that are very powerful. However, there are a few corruption issues related to LVOOP that have made me realize that without SCC I would be getting nowhere on my current LVOOP project. I think these principles also apply more generically to all LabVIEW project files.

There are several hurdles that will basically ruin your day when developing in LVOOP without a good backup system in place. SCC systems provide backup and version control for all of the files that you modify during the course of development which allows you to revert your code to a known state when your files get corrupted. SCC systems basically allow you to take snapshots of your project so that you can revert your code at a very granular level should the need arise. Using SCC should be important to anyone who wants to be able to work on code which means this document applies to solo-developers and not just people working on development teams. There are no excuses for not using an SCC system!

more…

LabVIEW 8.5 includes a new visual merge tool LVMerge that can be called from external source code control program for three-way VI merging. I’ll go trough the steps required to integrate LVMerge with popular TortoiseSVN source code control client.

If you have edited a VI that is under source code control, occasionally someone else may have edited the same VI after you have checked it out. As a result the two versions of the same VI are likely differ from each other. In three-way merging, these two different versions of the VI are compared agains a common base version of the VI. This way the merge tool can identify which of the changes have occured in both of the modified version since the VI was last checked out. LVMerge is a three-way merge tool and allows developers to visually compare all three versions of the VI. For each modification in either of the two modified version of the VI developer can choose if the modification should be ignored or included.

Setting up TortoiseSVN

To set up LVMerge with TortoiseSVN, right click on a directory under souce code control and select from the right-click menu and and then from the appearing submenu. TortoiseSVN Settings screen will open.

Select Merge Tool from the tree menu on the left and press Advanced… button on the right to open the advanced merge tool settings.

No, let’s define that files with extension .vi shall be merged with LVMerge. Tio do this, click Add… button. A dialog window with two fields Extension and External Program will appear.

For the Extension field fill in

.vi

For the External Program field fill in

“C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe” “C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe” %base %theirs %mine %merged

If your LabVIEW installation directory is not under C:\Program Files\National Instruments, mofify the path respectively.

Press Ok for all the open windows and you are done setting things up.

Accessing LVMerge to Resolve Conflicts

Now we are ready to resolve conflicted VIs. When TortoiseSVN encounters a conflict, it layouts a exclamation point on top of the file icon on windows explorer. The exclamation point indicates that the file is conflicted and that you need to manually resolve the conflicts.

To resolve the conflicts, right click on the conflicted file and select and from the appearing context menu. Now TortoiseSVN will call LVMerge to allow you to resolve the conflicts. LVMerge is a rather intuitive tool and I’ll not go into detail how to use it. You’ll come along.

After you are done with resolving conflicts, save the file with the proposed name and quit LVMerge. TortoiseSVN doesn’t automatically know that the conflicts are now resolved but you still need to thell this to TortoiseSVN. You can tell TortoiseSVN that all conflicts are now resolved by selecting and from the right click menu of the conflicted file. After you have resolved all conflicts in your project, you can commit your changes to the repository.

Note! When resolving conflicts this way, the merged version gets saved on top of your own version of the VI. If you make mistakes in the merge process, you may accidentally loose your own changes to the VI. This is a feature of TortoiseSVN.

Don’t forget to read Jim Kring’s recent post Using Beyond Compare as your TortoiseSVN Diff Program for ZIP Archives at Thinking in G.