Using LV with SVN

[germ]

Hello,

sorry to start a new thread on this, but my searches turned out posts that are mostly outdated or relate to SCC tools other than SVN.

 

So, we have decided to use SVN as our SCC platform. I have setup a VisualSVN server on our Windows 2012 Server and Tortoise SVN client on the developer machines. This is working quite nicely at the file level, but I wonder if we can get more functionality, especially VI comparison.

 

We are using the latest LV 2015 Full Development System (not Professional Development system). So I understand that I cannot use the lvdiff tool. I have however setup LVcompare as a tool for .vi files in the SVN Advanced Setup.

 

I found two SVN tools for LV:

1. JKI TortoiseSVN Tool. This has a somewhat steep price at $200 per developer (10% discount from 5 seats)

2. TSVN Toolkit from Viewpoint Systems. This is free. However, it states that the latest version supported is LV 2014.

 

I am interested in the experience from other users regarding:

Q1. Which of the two tools, if any, do you find useful and why?

Q2. Does TSVN Toolkit work with LV 2015?

Q3. Any other tips/suggestions for effectively using LV with SVN?

 

Your opinion and help is much appreciated.

 

Thanks in advance.

--germ

[ak_nz]

TSVN Toolkit works fine in LV2015. The only issue I have found is that exposing the SVN icon states onto the Project Explorer items is a bit of a network hog - as a project grows increasingly larger (100s of items in the project) then project operations tend to suffer. But other then that I have found it a useful tool with SVN repos, especially when it comes to keeping files on disk and items in projects in sync (eg. re-naming).

Edited November 19, 2015 by ak_nz

[hooovahh]

The ViewPoint systems one works fine and is newer, not that this means it is better.  But honestly I think using a toolkit is optional.  I've generally just always used the tortoise SVN which add right click menus in Windows Explorer.  

 

I also work in the Lock, Edit, Commit scheme, instead of the Edit, Merge.  What this means is files are read-only until you get a lock.  Once you get the lock the VI is now not read-only.  You make the changes you want, and then commit them which by default will unlock it, setting the file back to read-only, allowing someone else to update and lock. 

 

So if I'm working on a VI and I don't have the lock I will hit save, and LabVIEW will prompt saying it can't save it is read-only and the explorer window will be opened asking me where to save it.  I will in this window right click my file and get the lock.  I'll then cancel that window and save again, and this time it will save because I have the lock and it isn't read only.  I can do all the SVN operations I want from the explorer window, and don't need to invoke another tool like Viewpoint.  The only exception is for things like invoking compare, and rename, which generally needs to rename both in SVN and in an open project.

 

Note that if you have LabVIEW 32 bit on a Windows 64 bit, you'll want to install this additional installer to give the right click menus in 32 bit applications after installing the 64 bit tortoise client.  This is mentioned on the download page of tortoise SVN.

[germ]

The ViewPoint systems one works fine and is newer, not that this means it is better.  But honestly I think using a toolkit is optional.  I've generally just always used the tortoise SVN which add right click menus in Windows Explorer.  

 

I also work in the Lock, Edit, Commit scheme, instead of the Edit, Merge.  What this means is files are read-only until you get a lock.  Once you get the lock the VI is now not read-only.  You make the changes you want, and then commit them which by default will unlock it, setting the file back to read-only, allowing someone else to update and lock. 

 

So if I'm working on a VI and I don't have the lock I will hit save, and LabVIEW will prompt saying it can't save it is read-only and the explorer window will be opened asking me where to save it.  I will in this window right click my file and get the lock.  I'll then cancel that window and save again, and this time it will save because I have the lock and it isn't read only.  I can do all the SVN operations I want from the explorer window, and don't need to invoke another tool like Viewpoint.  The only exception is for things like invoking compare, and rename, which generally needs to rename both in SVN and in an open project.

Can you share how you set this up? Is it a setting in Tortoise SVN?

 

Note that if you have LabVIEW 32 bit on a Windows 64 bit, you'll want to install this additional installer to give the right click menus in 32 bit applications after installing the 64 bit tortoise client.  This is mentioned on the download page of tortoise SVN.

Yes, I did notice that. Thanks.

[Mellroth]

So if I'm working on a VI and I don't have the lock I will hit save, and LabVIEW will prompt saying it can't save it is read-only and the explorer window will be opened asking me where to save it.  I will in this window right click my file and get the lock.  I'll then cancel that window and save again, and this time it will save because I have the lock and it isn't read only.  

 

I use TortoiseSVN exactly like this, I only want to point out that the main reason I press cancel and then save again is that this prevents me from saving over another file by accident.

 

You set this up in the TortoiseSVN client configuration file.

1. Enable auto props (uncomment ###enable-auto-props = yes)

2. add a line at the end of the [auto-props] section that reads *.* = svn:needs-lock=True

 

You can also have a pre-commit hook set on the server to detect if any commited file lacks the needs-lock property.

 

/J

[MikaelH]

We started using TSVN Toolkit from Viewpoint Systems, which is a great add-on, but for most of our LV developers it started to make LV too slow, since our projects are often very large.

So we’ve gone back to just using TortoieseSVN (and with a quick drop shortcut that brings us straight to the file in the explorer window).

We prefer the Edit, Merge option for out projects.

[joerghampel]

I've generally just always used the tortoise SVN which add right click menus in Windows Explorer.  

 

I'm using git, but all of my customers who go with SVN use the Tortoise SVN client and are happy with it.

[germ]

The ViewPoint TSVN toolkit does not work with the latest 1.9.x version of Tortoise SVN client. I have emailed ViewPoint but have not gotten a reply yet.

[ThomasGutzler]

The ViewPoint TSVN toolkit does not work with the latest 1.9.x version of Tortoise SVN client. I have emailed ViewPoint but have not gotten a reply yet.

 

Yes, we found they usually lag behind current for a bit. Just adds to the pile of inconveniences leading to uninstall :/

[ak_nz]

Yes, we found they usually lag behind current for a bit. Just adds to the pile of inconveniences leading to uninstall :/

 

Doesn't the toolkit use SharpSVN internally? You could probably manually over-write this assembly with the latest online and chances are it would work.

[parthabe]

On 11/19/2015 at 7:27 PM, hooovahh said:

Note that if you have LabVIEW 32 bit on a Windows 64 bit, you'll want to install this additional installer to give the right click menus in 32 bit applications after installing the 64 bit tortoise client.  This is mentioned on the download page of tortoise SVN.

Hi,

Am not able to install "vc_redist.x86.exe" on my Win10Pro 64-bit for LV2016 32-bit! It says "Another version of this product is already installed." What should I do now?! Please see to the attached install log & help/guide me.

dd_vcredist_x86_20170628181430.log

[hooovahh]

28 minutes ago, parthabe said:

Am not able to install "vc_redist.x86.exe" on my Win10Pro 64-bit for LV2016 32-bit! It says "Another version of this product is already installed." What should I do now?! Please see to the attached install log & help/guide me.

dd_vcredist_x86_20170628181430.log

Well the purpose of this was to enable right click menus in explorer 32-bit.  Do you have this?  If not I'd suggest going to the SVN forums, or support to see what others have done to get around this.

[bmoyer]

I see that PushOK SVN is listed as a recommended SCC Provider in LabVIEW.  Has anyone tried to use this?  I tried but ran into difficulties because the initial connection when LabVIEW started was taking too long and timing out.

Which Third-Party Source Code Control Providers Does National Instruments Recommend for LabVIEW 8.x and Later?

http://digital.ni.com/public.nsf/allkb/41FBD516D8BC1DED862576AF007061B2

 

[parthabe]

17 hours ago, hooovahh said:

Well the purpose of this was to enable right click menus in explorer 32-bit.  Do you have this? 

I think, yes! Is this what you mean?!

 

 

[A Scottish moose]

I've used Tortoise SVN since 2010 and really like it.  I recommend it to everyone. 

used the Viewpoint tool for a little over a year and really enjoy it as well.  As mentioned above it's very useful when having to do the same rename/delete function on a file and your SVN repo at the same time.  Saves a lot of conflict and missing file dialog headaches.

On 11/22/2015 at 4:00 PM, MikaelH said:

We started using TSVN Toolkit from Viewpoint Systems, which is a great add-on, but for most of our LV developers it started to make LV too slow, since our projects are often very large.

So we’ve gone back to just using TortoieseSVN (and with a quick drop shortcut that brings us straight to the file in the explorer window).

We prefer the Edit, Merge option for out projects.

If you don't mind me asking... at what size of project do you start to see these problems?  Most of my projects are in the 200-500 VI range.  I haven't noticed any major impact at this point...

 

On second thought I have noticed LabVIEW using a lot more processor time than I would expect it too lately but didn't attribute it to the VP-SVN add-on. Perhaps I should do some testing on that.

 

[hooovahh]

13 hours ago, parthabe said:

I think, yes! Is this what you mean?!

Yup looks like you're all set and don't need to install that extra thing I linked to.

[Rolf Kalbermatter]

On 6/28/2017 at 3:30 PM, bmoyer said:

I see that PushOK SVN is listed as a recommended SCC Provider in LabVIEW.  Has anyone tried to use this?  I tried but ran into difficulties because the initial connection when LabVIEW started was taking too long and timing out.

Which Third-Party Source Code Control Providers Does National Instruments Recommend for LabVIEW 8.x and Later?

http://digital.ni.com/public.nsf/allkb/41FBD516D8BC1DED862576AF007061B2

That's a very old recommendation back in the days when NI added source code control integration to LabVIEW (version 6 or 7 or something like that). They used the Microsoft source control API for that which was only really supported for the now defunct Microsoft Source Safe offering. Some companies developed additional plugins for that API that interfaced to other source control solutions but the Source Safe API used the old checkin/checkout methodology like what CVS had been using and didn't support any of the other methods like what SVN, Hg and Git nowadays support. As such the Source Safe API was severally limited and never really could catch on, probably also helped by the fact that Source Safe was a notoriously bad source control system, that could actually corrupt your source code randomly if you were unlucky.

NI later improved the source control interface in such a way that you could install LabVIEW based source control provider plugins, so if you want to use SVN and have it integrated in LabVIEW directly you should probably install the Viewpoint SVN plugin instead.

The only problem with LabVIEW based project plugins is however that they can affect the performance of LabVIEW IDE operations. There have been reports that installing any of the LabVIEW SVN plugins start to severely impact edit time performance if a LabVIEW project file reaches a certain number of VIs. But PushOK SVN is certainly the worse solution for use with LabVIEW.

That all said we use SVN for our development, but we usually don't install any source code control plugin in LabVIEW. Most simply use the Tortoise SVN Windows shell integration. You have to be careful when moving, renaming, or deleting files as you have to make sure to first do those changes in Tortoise SVN and then change the project to reflect the new situation but it works pretty well if you keep yourself disciplined. 

Edited August 1, 2017 by rolfk

[A Scottish moose]

11 hours ago, rolfk said:

That's a very old recommendation back in the days when NI added source code control integration to LabVIEW (version 6 or 7 or something like that). They used the Microsoft source control API for that which was only really supported for the now defunct Microsoft Source Safe offering. Some companies developed additional plugins for that API that interfaced to other source control solutions but the Source Safe API used the old checkin/checkout methodology like what CVS had been using and didn't support any of the other methods like what SVN, Hg and Git nowadays support. As such the Source Safe API was severally limited and never really could catch on, probably also helped by the fact that Source Safe was a notoriously bad source control system, that could actually corrupt your source code randomly if you were unlucky.

NI later improved the source control interface in such a way that you could install LabVIEW based source control provider plugins, so if you want to use SVN and have it integrated in LabVIEW directly you should probably install the Viewpoint SVN plugin instead.

The only problem with LabVIEW based project plugins is however that they can affect the performance of LabVIEW IDE operations. There have been reports that installing any of the LabVIEW SVN plugins start to severely impact edit time performance if a LabVIEW project file reaches a certain number of VIs. But PushOK SVN is certainly the worse solution for use with LabVIEW.

That all said we use SVN for our development, but we usually don't install any source code control plugin in LabVIEW. Most simply use the Tortoise SVN Windows shell integration. You have to be careful when moving, renaming, or deleting files as you have to make sure to first do those changes in Tortoise SVN and then change the project to reflect the new situation but it works pretty well if you keep yourself disciplined. 

On the topics of edit time performance....

 

Over the last month I've been developing a test system that is now around 650 custom Vis in memory at one time. I started to notice a quickly increasing load on windows from LabVIEW towards the end of the project that disappeared after removing the SVN toolkit.   I'm sure it depends on the processing power of your machine but I find that the 500+ VI projects start to see some major impact from the Viewpoint add on.  It's a fantastic tool, but that's the trade off.

 

Cheers,

Tim