LabVIEW Development Best Practices Blog

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Using Subversion (SVN) with LabVIEW

Elijah_K
Active Participant

As anyone who has asked me about source code control knows, I've become a very big fan of Subversion; specifically, TortoiseSVN.  I originally started using it because a large number of NI customers I was speaking with had made the switch, due in no small part to the price tag (it's free).  But it's not just the price that makes it so appealing - TortoiseSVN is very easy and simple to use, which makes it something that makes you more efficient, rather than weigh your development process down.

If you're not using source code control at all, you're playing with fire.  And since Subversion is free, you now have no excuse.  Still not convinced?  Has any of the following ever happened to you:

  • You delete or change some code as part of an experiment or perhaps debugging, and then save it.  If you want to undo these changes, you have to redo it yourself.
  • You want to experiment with a new implementation or function, so you save the old VI or project to 'My Project OLD,' to make sure you have your backup handy. (Now you have a bunch of other copies of your application all over your laptop and your network drive).
  • You want someone else to look at your code or even modify it. (again, you put a copy on the network folder or a jump drive... but when you make a change, you have to go do it all again!)
  • You open an older copy of your application or a copy saved in a different location, causing a link conflict (lets face it, fixing this is not fun)
  • You introduced a bug into your code a few days ago and want to revert to an older version to figure out what changed (too bad)
  • An angered or jealous C developer steals your laptop and destroys it, taking with it the only copy of your code. (that's what you get for under-bidding him by 3X)

Any of these could've been avoided or made easier if you'd been using source code control.   So go download Subversion!  Go here.

UPDATE (7/29/13)

There is now a free plugin from Viewpoint Systems that sets up integration with Tortoise for you (including diff and merge) and overlays the icons in the Project Explorer - the best part is that it's totally FREE.  I strongly recommend that anyone using SVN+LabVIEW install this tool.  The latest version can be found here: Subversion Version Control for LabVIEW. Please make sure you already have Tortioise installed - if you don't, make sure to restart your computer after installing Tortoise.  You'll also need to restart LabVIEW after installing this plugin.  Enjoy!

Tip 1

If you're going to use Subversion with LabVIEW, you need to know a few things.  Subversion stores some hidden folders and files in your directory structure, which can cause some problems when mass compiling or using auto-populating folders.  Not to worry!  Open your labview.ini file and enter 'skipSVNFolders=true' to resolve this issue (only works in 2009, will be on by default in 2010).

Tip 2

If you're using the professional version of LabVIEW, you can tell Subversion (or any source code control tool) to invoke the command-line diff and merge executables.  To set this up, right click in Windows Explorer and select TortoiseSVN > Settings.  Select Advanced and enter the following for a .vi file type (this can also be used for a .ctl)  "C:\Program Files\National Instruments\Shared\LabVIEW Compare\LVCompare.exe" %mine %base -nobdcosm -nobdpos.  Do the same for merge, but enter "C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe" %base %mine %theirs %merged.  The command line parameters are explained in the LabVIEW help, click here for LVCompare.exeMore info on command-line differencing.

Getting Started with Subversion

If you've never used source code control and want to give it a try, check out this hands-on exercise and example program I published here: http://decibel.ni.com/content/docs/DOC-10122

As for experienced source code control readers and users, what packages are you using, and do you have any tips for use with LabVIEW?  Is anyone using Git or Mercurial? (two other popular open source SCC providers)

Elijah Kerry
NI Director, Software Community
Comments
mprimrose
Member

We use VisualSVN Server and TortoiseSVN every day.

VisualSVN Server is by far the easiest Subversion server to install and maintain, and the standard edition is free.  It is available here:  http://www.visualsvn.com/server/

TortoiseSVN is very easy to use although I highly recommend creating an ignore list to avoid committing unnecessary files.  More info about exclude/ignore here: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-ignore.html

A useful Subversion tool for tracking changes to repositories is Commit Monitor (from the author of TortoiseSVN) it allows you to track commits to a repository,  ie track what others have committed.  It is available here:  http://tools.tortoisesvn.net/CommitMonitor.html

Another useful tool for tracking the status of working copies is SVN Notifier located here:  http://svnnotifier.tigris.org/  Unlike the Commit Monitor tool above, this tool displays the current status of working copies and provides shortcuts to Commit / Update the tracked copy.  We use this to ensure that working copies are updated.

11-14-11 Updated links removed old software reference.   mp

jon_mcbee
Active Participant

This is slightly off topic, but does anyone use Trac with Subversion?  Trac is an issue tracking system that ties into subversion in a way that lets you link your versioned files to Trac issues.  Just curious if anyone has any thoughts, positive or negative, about using the two together.

PaulLotz
Member

We don't use Trac but we do have this capability with our issue tracker (JIRA) and its related tools (FishEye or Crucible actually handles the linking, I understand).  When we check something in to Subversion that is related to a JIRA issue, we mention the JIRA issue in the check-in text and then a few moment later the text and the check-in details automatically appear in JIRA.  This is quite a convenient feature indeed!

soupy
Member

The good

  • supports workflows
  • can browse SVN repository and log through trac
  • adding special tags to SVN release notes auto-adds info to trac ticket

The bad

  • wiki formatting is primitive and annoying
  • users can't delete ticket attachments without having tons of access rights

Overall, I like it. Just note that trac is a bug tracking system so it can't really control your revision control workflow. It is just used for guidance.

xcEric
Member

I use Trac at home and JIRA at work, both with subversion.

Trac is incredibly easy to set up and very free. VisualSVN users can check out this page. I tried that first, but recently switched all my services to a separate Linux machine, which is almost easier than getting it running in Windows (and definitely cleaner). Trac is great, but is very basic, and a little cumbersome to use. Perfect for a team of 1. I can definitely give more in depth install and setup advice to anyone who needs it for Linux.

JIRA on the other hand is very powerful and feature rich. I like it a lot for our much large development team at work. Trac just doesn't cut it for a large team with diverse development needs. I have not had as much experience setting it up since our IT department does that, but I am working on integration with TortoiseSVN.

Eric
--
"When I see an adult on a bicycle, I do not despair for the future of the human race."
-H.G. Wells
mprimrose
Member

Has anyone tried this subversion server:  http://www.svnisapi.com/

rolfk
Knight of NI

SVNsapi sounds to me a lot like marketing hype. As if usage of Microsoft only components is any better guarantee that you can't get compromised than using OSS. They do use the SubVersion kernel anyhow in form of DLLs which originates not from Microsoft, so that point is at least partly already moot.

What else? It seems like a commercial product so you could say you pay for what you get but that does not really go well with nowadays more popular open source software anymore.

"No Apache Server or SVNSERVE instance required

SVNSERVE is so easy to install it is a no brainer. The problems about it are if you want individual user authentification.  Apache is a bit more of a hassle to install, especially if you want to integrate it in an LDAP environment, but hey installing Windows Server AND configuring that it works reliable and right isn't exactly child work either. I guess if you have a Microsoft Professional Certified or similar centered IT departement this point is indeed an advantage of SVNsapi, but to me this is the only real advantage of all the marketing hype on that site.

"Secure, Reliable and performant Operating System and WebServer"

Apache isn't exactly insecure.

"SVNIsapi provides you with a secure manner to host Subversion  repositories, due to the lack of having to operate non Windows components, or TCP/IP protocols"

As if the Microsoft Winsock implementation wouldn't have had any security holes.

"Support for Integrated Windows Authentication (IWA)"

I guess this is indeed a possible advantage, though I'm not sure using the same credentials for all services in a company is necessarily a good idea.

"Direct Integration in a Windows Domain using Active Directory"

Apache does this with LDAP which Windows supports too.

"Benefit from the Windows Server built-in security, backup or  high-availability features - like the Network Load Balancing (NLB) Service - by using only  Windows native componet

Not sure about this, I would expect this to work mostly on winsock level or below so why wouldn't Apache or such profit from that too?

Rolf Kalbermatter
My Blog
Paul_F-MCP
Member

Hi,

not being a software engineer I've not used source control to date although I am aware of it and the benefits it can provide. Having installed the Tortise SVN suggested here I'm now a little puzzled on how best to use it. In LabVIEW Tools/Options under source control it still doesn't list and source control providers - does this mean I've installed it incorrectly, or that I need to do something else (install a server maybe?) or manually check out and update files via the Tortoise SVN Repo Browser?

Sorry if these are numpty queries.

Paul

Regards

Paul

CLD running LabVIEW 2012 32 & 64 bit on Windows 7 64 bit OS.
tstanley
Active Participant

Anyone have any experience using SVN (or Bazaar or Mercurial) with LabWindows/CVI?

rwunderl
Member

Paul,


LabVIEW does not "support" SVN, so you need to get JKI's tool in order to integrate TortoiseSVN into the LabVIEW environment.


This is a real pain and in my opinion NI should add native support for this software since it is so widely used. If using TortoiseSVN in LabVIEW were as easy as using Microsoft VSS, our company would have already adopted it. (We tried out an older version of VSS just to see what version control in LabVIEW was all about, and it worked marvelously; however, the cost of implementing a new version remains an issue.)

_______________________________________________________________
"Computers are useless. They can only give you answers." - Pablo Picasso
K1200LT_rider
Member

I've tried Mercurial with text-based projects, and I like it.  Haven't tried it with LabVIEW stuff, and I've never used SVN.  I hope Mercurial is supported in the future by NI or JKI.

Paul_F-MCP
Member

Hi rwunderl,

thanks for that - I'd found the link to the JKI tool, but have shyed away from installing it. I might be over cautious, but the idea of using a bolt on worries me from a future compatibility point of view (although I suspect JKI will make sure that's not an issue).

One think I have found from my digging is that Perforce is claimed to be fully integrated for all platforms and is free for a two user license. When I can get a bit of spare time I think I'll give that a try.

Regards

Paul

CLD running LabVIEW 2012 32 & 64 bit on Windows 7 64 bit OS.
TCPlomp
Trusted Enthusiast

It would be very usefull if NI provided an 'empty' source control provider which we can alter to our needs.

I'm using Mercurial and it would be very usefull if I can use the Project integration.

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
D*
Member
Member

Is the merge command line file order slightly off?  From the LV Help doc the order is : base, theirs, yours, merge :

LVMerge.exe "C:\Program Files\National Instruments\LabVIEW 8.6\LabVIEW.exe" c:\files\base.vi c:\files\theirs.vi c:\files\yours.vi c:\files\merged.vi.

Taggart
Active Participant

any tips for branching/merging involving lvclass and lvlib files?

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
JCC_(SK)
Active Participant

My advice will be: Do not do it!

🙂

Your (and your colleges) life will be easier when only one developer will modifying class/lvlib.

I thing that classes and lvlibs should be small code as possible and after that you don't need more developers per one class/lvlib

JimMacD
Member

@mprimrose

I'm looking at setting up VisualSVN Server and TortSVN.

1 question: What is your backup strategy? I have been looking for an automated script to run on Windows

-Search Repository Folder for Repo's
-Perform Hotcopy backup
-Verify Backup is ok
-e-mail a notification if backup is not ok

--------------------------------------------------------------------------------------------------

--CLD--
LV 6.1 to 2015 SP1
Elijah_K
Active Participant

I personally use a combination of CrashPlan and Acronis for off-site backups and local HD mirroring, respectively.

Elijah Kerry
NI Director, Software Community
JimMacD
Member

Do you perform a hotcopy backup of SVN repository 1st, or just copy the Repository folder?

--------------------------------------------------------------------------------------------------

--CLD--
LV 6.1 to 2015 SP1
mprimrose
Member

We backup the repository daily as well as dumping each revision using the following script as a post-commit-hook, this script requires a "revs" directory:

set REPOS=%1

set file_name=%~nx1

set REV=%2

set REV_DIR=%REPOS%\revs

"C:\Program Files (x86)\VisualSVN Server\bin\svnadmin" dump %REPOS% --revision %REV% --incremental >> %REV_DIR%\%REV%.dmp 2>>"%REPOS%\revs\%file_name%.err"

"%VISUALSVN_SERVER%\bin\VisualSVNServerHooks.exe" ^

    commit-notification "%1" -r %2 ^

    --from engadmin@company.com --to engsvn@company.com ^

    --smtp-server smtp.company.com

sampledout
Member

Is it worth implementing TortoiseSVN in a single developer environment where the Developer only has Labview Full (not Professional). I ask this because most of the posts about Subversion etc. talk about LVCompare Graphical Diff which only appears to come with Labview Professional. Without access to this LVCompare, is there any point to implementing TortoiseSVN with Labview?

jcz
Member
Member

I'd say it definitely is worth working with TortoiseSVN even if you can't use the Graphical Diff feature. That way you'll get into habit of working with revision control system. And some day you might benefit from it.

Pete.Dunc
Active Participant

In my opinion, definitely

Everytime you check-in some code you have the option to annotate with notes - this can help massively when something breaks and you need to trace what might have gone wrong.  Although having a Diff tool is useful, you can still open two revisions side-by-side - and revert if need be.  The act of checking in code should be a mental tick to think about what you're changing and note it down.

You can tag when you hit milestones in development, and have that code locked down in a safe place should your client require a progress update.

And.. if you have SVN on your machine you can also use it to track other types of files - almost everything in my workplace is now worked on from an SVN server - for the same types of reasons as above.  "What did I edit in that version of the *.doc / *.xlsx ?" questions are much easier to answer.


Regards,

Peter D

sampledout
Member

Many thanks to you all for your coments. I just thought that if the difference checking wasn't available then it would not work at all, but you have cleared that up. I will implement right away.

Elijah_K
Active Participant

This post reminded me to update this document.  If you didn't see it already, please read the note about the new plugin from Viewpoint.  I highly recommend it (and it's free).

"There is now a free plugin from Viewpoint Systems that sets up integration with Tortoise for you (including diff and merge) and overlays the icons in the Project Explorer - the best part is that it's totally FREE.  I strongly recommend that anyone using SVN+LabVIEW install this tool.  The latest version can be found here: Subversion Version Control for LabVIEW. Please make sure you already have Tortioise installed - if you don't, make sure to restart your computer after installing Tortoise.  You'll also need to restart LabVIEW after installing this plugin.  Enjoy!"

Elijah Kerry
NI Director, Software Community
jcarmody
Trusted Enthusiast

I installed it and like what I see.  The glyphs in the project explorer will trigger me to commit more frequently.  This is evaluation software, though, and I couldn't find any information about an evaluation period or full-version price. What's going to happen after I fall in love with it only to find that it times out?

tsvn.jpg

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Nancy_Hollenback
NI Employee (retired)

It's free! Newer version will be compatible with 2013.  Don't forget - Install 1.7.x of Tortoise, not the current 1.8 - either 32 bit or 64 bit works great.

Bob_Schor
Knight of NI

Why are you suggesting we not install 1.8?  What "breaks"?  [I was planning to update shortly ...].

Nancy_Hollenback
NI Employee (retired)

I can't tell you what specifically breaks, only that the install of the toolkit did not work.  Toolkit will be updated soon for 1.8 - likely posted first on Viewpoint's site, then shortly thereafter, available from ni.com/toolsnetwork.

Elijah_K
Active Participant

The newest version adds some awesome Quick Drop shortcuts.  CTRL+C commits, for example.  Learning the rest is on my todo list, but that one has already saved me significant time.

Elijah Kerry
NI Director, Software Community
fredb
Member

We stopped using SVN when we realized that merging was not fully supported. Still excellent source control if you use it with locks. And Free. The need to merge has less to do with the size, complexity, or number of developers. It has more to do with workflow. I have qualified and released something. I have a brilliant idea (they are always brilliant at first) and start making changes. While in the middle of my changes, one of my previously brilliant ideas proves to be, ahem, less than brilliant, and I now need to go to my released code, make a change, qualify it, and re-release. Now that I've wiped all that egg off my face, I go back to my newly brilliant idea, finish all my changes, and, what I really want (need?) to do, is merge the changes in, lest I re-introduce the previous problem. Typically we work with concepts of 'development', 'integration', and 'release' streams.

This is the most trivial instance that I could think of for when a full merge capability is required. Now envision supporting multiple development streams for multiple projects with multiple engineers. I believe this is the problem that triggered the evolution from Source Control, to Software Configuration Management.

Putting on fire resistant suite... hold on.... ok - ready! Flame away. Better yet, tell us that 2013 now supports merging of project, classes, and libraries.

SeanDonner
Active Participant
We stopped using SVN when we realized that merging was not fully supported

That statement doesn't jive with me because you point TortoiseSVN to the LabVIEW Merge tool that comes with LabVIEW Pro & Dev Suite.  To be fully open and honest, the last time I did a LV merge was about a year ago on a sample VI just to test that it works; so I really can't talk to the capabilities of the LVMerge.exe tool but I will say it sounds like your problem lies there and not the SCC tool, i.e. SVN.   Even if merge capability was completely absent, SCC still has a tremoendous amount of value to offer; so I really hope you reconsider using some flavor of SCC, be it SVN, Mercurial, Git etc.

Every change you make outside of a SCC environment is an attempt to charm the snake; you do it enough times and you WILL get bit.


Taggart
Active Participant

We stopped using SVN when we realized that merging was not fully supported

I think the point fredb is trying to make is that merging of .lvproj, lvlib, lvclass and similar files is not yet supported.  There is no merge utility for these files, and any attempt to manually do so usually results in a corrupted file.

This applies to all SCC providers, not just SVN.  Is is due to the nature of the files.

It is most certainly still worth using some form of SCC, but this issue definitely warrants some careful consideration.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
fredb
Member

Thanks Taggart, that is the point. The only issue with SVN (which may be more pilot error) is that the model is: all files are Read / Write, and then one merges changes. No gripes with SVN - that is a good model. Seriously.

We still use source control, and would never dream of not using it (and no, you're not allowed to ask why I'm still stuck using VSS - not my choice!)

EricLM
Member

Nothing "breaks" per se, but up until a couple weeks ago, there was no 1.8, so the underlying libraries that operate on the working copy are the 1.7 flavor, so they will not recognize a 1.8 working copy. Any commands that call TortoiseSVN directly will still work. So, you will not see icon overlays among other things, but some of the menu commands may still work.

There will be a new compile for 1.8 on our website in the next day or so. I plan for the next release on LVTN to support 1.7 or 1.8 (with a toolkit reinstall that is). I will post on here when it is up.

Nancy_Hollenback
NI Employee (retired)

Ironically, I was working on a blog post on the TSVN Toolkit last week.  It is finally posted at www.labviewjournal.com.  I include a few common getting started questions that we might ask.  Like Eli,  I'm really excited about this tool!  And I'm also eager to see what time-saving features Viewpoint has in store in future versions.

DCSmith
Member

Just installed the Viewpoint toolkit this morning.  So far, i'm digging it

Pie566942.0
Member

I've been using Viewpoint Systems' tool since it was featured in NINews.  Adding, Diffing, Reverting and Committing from the LabVIEW project work flawlessly in 2011.  With projects that live across directories and include Externals, the tool's enabled me to isolate my commit and add specific notes far easier than using SVN from the shell.  It's been a pleasure to work with.

I don't need a multi-developer SCC; but I develop from multiple machines.  It only took one awful conflict for me to learn my lesson, which also eliminated my use for LVMerge.  As rules of thumb:

  • I start an implementation session by updating.
  • I end an implementation session by committing.

It sounds like common sense, but for some reason it took a conflict to drive it into my practice.

I wish the toolkit directly supported renaming project items that have been committed and moving items on disk.  I often have this need when inheriting code that I want to lay out differently.

Elijah_K
Active Participant

You're not alone.  Most people, myself included, have to get burned once to really understand the value of SCC.  🙂

Elijah Kerry
NI Director, Software Community
Pie566942.0
Member

It was actually my improper use of SCC that burned me.

Resolving Conflicts:

     

A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. 

In my case, it only took one developer

Active Participant

Elijah_K wrote:

You're not alone.  Most people, myself included, have to get burned once to really understand the value of SCC.  🙂

Wait till you get burned by your Internet connection or a heavily branched development tree. Then you'll really understand the value distributed VCS like Hg and Git.

Nancy_Hollenback
NI Employee (retired)

What's your preferred between Hg and Git?

Active Participant

Git. Hg has already capitulated.

Daklu
Active Participant

Git. Hg has already capitulated.

                   

Can you elaborate?  I haven't heard anything about Hg throwing in the towel.

What's your preferred between Hg and Git?
                   

My personal preference is Hg, primarily because when I transitioned from SVN Hg was more approachable and had better Windows tools.  The Git vs Hg conflict reminds me of the Ford vs Chevy debates of years past--fueled by their respective fans and irrelevant to almost everyone else.  You can't go wrong with either.  Both do the job admirably and are (imo) a clear improvement over SVN.  Here's hoping Viewpoint ports their tool to support Git/Hg. 

Elijah_K
Active Participant

Also very interested to hear if others agree that Hg is 'so last year' already.

Elijah Kerry
NI Director, Software Community
elset191
Active Participant

Here's a relevant discussion on the CLA group https://decibel.ni.com/content/docs/DOC-27011

--
Tim Elsey
Certified LabVIEW Architect
soupy
Member

in regards to merging, my team has had some good success once we understood what could and couldn't be merged. you shouldn't discount this tool entirely. when used properly, it will save you a lot of time.

lvmerge tips

  • avoid conflicting large VIs. attempting to lvmerge them will result in a crash. this is a sign that your modularity index is out of control!
  • keep your modularity index in check. syle guide recommends at least a 3, my team averages about 5. with things divided up into smaller pieces, two developers are less likely to modify the same thing and the smaller block diagrams are almost guaranteed to merge
  • don't "re-write" sections of code if it isn't necessary. lvmerge has a hard time successfully merging complex changes like this. the time you save by re-writing things now may be null'd by your merge efforts later.

class/library/project tips

  • simple add/delete/rename actions typically successfully merge
  • don't expect complex changes to work (e.g. reorganizing the virtual folder structure)

general tips

  • don't do complex things and expect it to work. this is true for ANY merge utility. if you delete lage sections of code and re-write, don't expect it to be able to merge.
  • communicate with your team to avoid merging in the first place. merging always adds some schedule risk, avoid if possible.
Active Participant

Daklu wrote:


Can you elaborate?  I haven't heard anything about Hg throwing in the towel.                   

Jack already did here: https://decibel.ni.com/content/docs/DOC-27011#comment-29651

My personal preference is Hg, primarily because when I transitioned from SVN Hg was more approachable and had better Windows tools.  The Git vs Hg conflict reminds me of the Ford vs Chevy debates of years past--fueled by their respective fans and irrelevant to almost everyone else.  You can't go wrong with either.  Both do the job admirably and are (imo) a clear improvement over SVN.  Here's hoping Viewpoint ports their tool to support Git/Hg.                    

Git/Hg both have solid Windows tools, now that Git Extensions is released. I've been using it for several months and love love love it.

DVCS (Git/Hg) vs. CVCS (P4/SVN):

- CVCS has locks and externals, both very useful when developing binary (LV) code

- DVCS can branch/merge without having to structure the repo carefully ahead of time. My brain melts whenever I try to create a branch in SVN.

- DVCS doesn't need to call home to a remote server. Invaluable when locked in a client's basement laboratory for a day.

Active Participant

My rule of thumb: Never merge LV XML code. You always end up corrupting something in your project/class/library subtlely and won't know it until several commits later.

GabbyG
Active Participant

I am still using TSVN on two people project with a cloud based server.

We are fine, even if we have to a lot of diff sometimes.

The only xml-style file that Tortoise tries to merge is the lvproj itself (I am the one that does the LVOOP ) .

That lvproj-merge usually goes completly havoc. You better call your partner and ask whats new or stay back and try to fit your modifications in the project tree manually.

Gabi

7.1 -- 2013
CLA