Jump to content

Article - Fighting Corruption: Using Source Code Control Systems


Recommended Posts

QUOTE (Omar Mussa @ May 16 2008, 09:45 AM)

I just posted an article: Fighting Corruption: Using Source Code Control Systems (SCC) with LabVIEW Class Files to ExpressionFlow.com.

The article highlights ways that LabVIEW class and project data can be corrupted and some SCC practices that can help you to recover from them.

There is no mention of using the built in LabVIEW SCC integration. Do you use it? If not, why?

Link to comment

QUOTE (gmart @ May 16 2008, 09:35 AM)

There is no mention of using the built in LabVIEW SCC integration. Do you use it? If not, why?

Good point, I haven't tried using built in SCC integration for a while. The main reason I stopped was that I have different SCC repositories/servers for different projects and in the past LabVIEW SCC could not handle that. I haven't looked into it for a while but just from quickly looking at the LabVIEW 8.5 SCC options it doesn't look like that has been addressed.

I'm currently using TortoiseSVN from Windows Explorer for all of my SCC operations.

Link to comment

QUOTE (Omar Mussa @ May 16 2008, 11:09 AM)

Good point, I haven't tried using built in SCC integration for a while. The main reason I stopped was that I have different SCC repositories/servers for different projects and in the past LabVIEW SCC could not handle that. I haven't looked into it for a while but just from quickly looking at the LabVIEW 8.5 SCC options it doesn't look like that has been addressed.

I'm currently using TortoiseSVN from Windows Explorer for all of my SCC operations.

8.5 allows you to configure the SCC proejct on a per LabVIEW project level. You still have to enable SCC at an environment level. Also, only one SCC provider is supported even on a per LabVIEW project level. What SCC package do you use?

Link to comment

QUOTE (gmart @ May 16 2008, 10:30 AM)

8.5 allows you to configure the SCC proejct on a per LabVIEW project level. You still have to enable SCC at an environment level. Also, only one SCC provider is supported even on a per LabVIEW project level. What SCC package do you use?

Omar mentioned that he was using TortoisSVN, so I'd assume (actually, I know) he's using Subversion. Using subversion with LabVIEW's SCC provider is like swimming against a current. Subversion wasn't designed for the check-in/check-out development model that LabVIEW and SCCAPI assumes, and there is no native support for Subversion. You have to use a third-party SCC API adaptor. All this just gets in the way of things, IMO.

Link to comment

QUOTE (Jim Kring @ May 16 2008, 02:24 PM)

Omar mentioned that he was using TortoisSVN, so I'd assume (actually, I know) he's using Subversion. Using subversion with LabVIEW's SCC provider is like swimming against a current. Subversion wasn't designed for the check-in/check-out development model that LabVIEW and SCCAPI assumes, and there is no native support for Subversion. You have to use a third-party SCC API adaptor. All this just gets in the way of things, IMO.

I understand SVN's development model is different. In general have you worked with an IDE (not client like Tortoise) that doesn't get in your way when using SVN (for example, Visual Studio)? Is the check in/out model such an impediment that even with the third-party SVN plugin for LabVIEW, you feel your productivity is diminished?

Link to comment

QUOTE (gmart @ May 16 2008, 01:44 PM)

I understand SVN's development model is different. In general have you worked with an IDE (not client like Tortoise) that doesn't get in your way when using SVN (for example, Visual Studio)? Is the check in/out model such an impediment that even with the third-party SVN plugin for LabVIEW, you feel your productivity is diminished?

> I understand SVN's development model is different. In general have you worked with an IDE (not client like Tortoise) that doesn't get in your way when using SVN (for example, Visual Studio)?

Take a look at any of the Java and/or open source IDEs: e.g., Eclipse, Apple XCode, NetBeans.

> Is the check in/out model such an impediment that even with the third-party SVN plugin for LabVIEW, you feel your productivity is diminished?

Ya, pretty much.

Link to comment

Your article does not specify what LabVIEW version can create these corruptions. There were two corruptions known in LV8.2, both of which were fixed in 8.2.1. There was one corruption associated with 8.5 that was fixed in 8.5.1. I do not have any open bug reports of any corruptions since then.

Please edit your article to specify which versions of LabVIEW are capable of creating these corruptions so that future readers don't continue to wonder if these are issues. It's irresponsible, in my opinion, to post an article such as this one without providing the version information. This article will still be available for reading -- and thus indexed by search engines -- years from now. Without a version number, this article becomes a source of FUD.

Your article opens with "a recent post on LAVA made me realize that this may still be useful." I'd just like to point out that the recent post on LAVA that you cited explicitly mentions that, no, he is not using LV Classes. If you know of any way by which the project and or class files can become corrupted that is not addressed by LV8.5.1, please report them ASAP so they can be fixed.

Link to comment

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)

I don't think it matters 'how' classes or projects get corrupted. I was trying to mostly point out that there are aspects of classes (and projects) that if corrupted are irrecoverable. A VI can similarly get corrupted (call it the neutrino effect) but it happens (though luckily very occaisionally for VIs). The point is, unless you are using an SCC system while you're making changes to code (especially code that is binary in nature) then you are risking losing your work and not having an efficient way to recover.

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)

Please edit your article to specify which versions of LabVIEW are capable of creating these corruptions so that future readers don't continue to wonder if these are issues. It's irresponsible, in my opinion, to post an article such as this one without providing the version information. This article will still be available for reading -- and thus indexed by search engines -- years from now. Without a version number, this article becomes a source of FUD.

I've been using 8.5 (I have not been able to switch to 8.5.1 yet) and I've seen the issue related to the corrupt class that I documented in my article appear -- now, you get a dialog that tries to help you recover by asking if you want to 'Add the missing file to the class' but I've seen this operation crash LabVIEW (and I have not reported it -- sorry about that -- I think it mostly is due to my not wanting to try to figure out exactly what the problem is so that I can report it correctly -- am sure I am not alone in this). I will go back to the article and edit some of the version specific info though.

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)

Your article opens with "a recent post on LAVA made me realize that this may still be useful." I'd just like to point out that the recent post on LAVA that you cited explicitly mentions that, no, he is not using
LV
Classes. If you know of any way by which the project and or class files can become corrupted that is not addressed by LV8.5.1, please report them ASAP so they can be fixed.

I think that what made me realize I needed to finish the article was the fact that the poster was losing productivity due to a corrupt project -- which could have been equally prevented using SCC.

I would contend that it is possible (even probable) that there are still bugs that can corrupt LV Classes in LV 8.5.1 that have either 1) not been reported or 2) not been discovered that will still warrant using an SCC system to prevent loss of productivity. So I think the premise of the article still stands -- use SCC so that you can have less fear of corrupted files.

Link to comment

QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)

Your article does not specify what LabVIEW version can create these corruptions. There were two corruptions known in LV8.2, both of which were fixed in 8.2.1. There was one corruption associated with 8.5 that was fixed in 8.5.1. I do not have any open bug reports of any corruptions since then.

Please edit your article to specify which versions of LabVIEW are capable of creating these corruptions so that future readers don't continue to wonder if these are issues. It's irresponsible, in my opinion, to post an article such as this one without providing the version information. This article will still be available for reading -- and thus indexed by search engines -- years from now. Without a version number, this article becomes a source of FUD.

Your article opens with "a recent post on LAVA made me realize that this may still be useful." I'd just like to point out that the recent post on LAVA that you cited explicitly mentions that, no, he is not using LV Classes. If you know of any way by which the project and or class files can become corrupted that is not addressed by LV8.5.1, please report them ASAP so they can be fixed.

My SR is still open. Also if you (and the rest of JKI??) continue to use Subserversion, do you have any specific recommendations about setting it up for a single developer (yes, like me), working on a single computer (largely) using external HDs for backup (yes three in all) and needing to remain mobile, etc so NOT wanting to have an external server as part of the solution?

BTW, I do have an external server that is available but, ok call me old school, I don't like the security issues of having to network over the internet to have access to a repository. I would much prefer something that allowed me to keep the external HDs.

Link to comment

QUOTE (Val Brown @ May 16 2008, 05:07 PM)

BTW, I do have an external server that is available but, ok call me old school, I don't like the security issues of having to network over the internet to have access to a repository. I would much prefer something that allowed me to keep the external HDs.

I'm mostly in a single-developer situation, using Subversion & TortoiseSVN, but my repository lives on the server in my office and is externally accessible. From a security standpoint I have zero fears about it, for the following reasons:

  1. I access it using https. (is that the webDAV-enabled version? I always forget.)
  2. The SVN directory on the server is sandboxed away from everything else.
  3. I use strong passwords.

That having been said, if you prefer to keep the repository locally, Jim's linked advice above is good.

Link to comment

QUOTE (Jim Kring @ May 16 2008, 11:19 PM)

QUOTE (Jim Kring @ May 17 2008, 03:02 AM)

Hi Val,

For a one person, such as yourself, I would recommend setting up a local subversion repository and regularly backup the local repository onto your external drive/server. A while back, I wrote an article about how do this, using TortoiseSVN:

I am using Subversion and the LabVIEW integrated tool at home via the PushOK plugin. The repository resides on a local Ubuntu server.

I have hardly a problem with the locked not-checked out items in the LV project.

I am going to enjoy this, at work I created a tool that checked all the files in the project, and reported those that were either old, not checked in or not in SCC. If anyone is interested in testing, PM me. I will try to get it up to CR standars (shouldn't be too hard though it contains express VIs).

Doe anyone know how to setup a https subversion repository on Linux?

Somehow I can't get it right.

Ton

Link to comment

QUOTE (gmart @ May 16 2008, 04:44 PM)

I understand SVN's development model is different. In general have you worked with an IDE (not client like Tortoise) that doesn't get in your way when using SVN (for example, Visual Studio)? Is the check in/out model such an impediment that even with the third-party SVN plugin for LabVIEW, you feel your productivity is diminished?

Well it's not about for example Visual Studio or not but about if that IDE uses the SCC API. That API was specifically designed around the strict check in/check out philosophy and accordingly uses, enforces and even requires it. And that does not work well with SVN. Visual Studio certainly is not a very good IDE to use with SVN since it does really on the SCC API for its Source Code Control integration.

As others have said there are other IDEs that are a lot more flexible in how they interface to SCC systems and that work a lot better with SVN than Visual Studio.

Rolf Kalbermatter

Link to comment

QUOTE (Jim Kring @ May 17 2008, 07:00 PM)

The data corrouption of the backup can only occur if there are open connections to the repository at the moment of the backup. On a single user repository this can be easily avoided by not using the repository while backing it up. However, incremental backup is a nice feature if you don't want to keep many duplicates of your entire repository.

p.s. Never rely solely on incremental backups only. I once was using incremental backup software provided with Maxtor external harddrive. It ended up a catasrophy as for some reason the whole incremental backup database was corrupted and I was unable to restore anything from the backup. Of course the backup software never provided any indication that there could be some problems with the incremental backup database. Maxtor customer service never bothered to respond to my support requests when I tried to restore my stuff. Luckily only the boot sector of my backed up hardrive was damaged and I was able to plug the hardrive into another computer as a secondary hardrive and restore everything.

Link to comment

QUOTE (Omar Mussa @ May 16 2008, 04:45 PM)

I just posted an article: Fighting Corruption: Using Source Code Control Systems (SCC) with LabVIEW Class Files to ExpressionFlow.com.

The article highlights ways that LabVIEW class and project data can be corrupted and some SCC practices that can help you to recover from them.

I've been bitten by a couple of clss/project file mis-features in LabVIEW 8.2.1 (and as far as I know, though I've not exhaustively checked, 8.5.1).

One I detailed in this LAVAG thread - basically you can lock up a class file so that you need to use a text editor (or revert using your SCC system). This method doesn't rely on LabVIEW crashing and doesn't strictly corrupt the class file - it's all a perfectly legal albeit un-editable class.

The second one that strikes with depressing regularity is LabVIEW corrupting the project file. As far as I can work out the sequence goes like this:

* You have a project file that includes several files in different directories with the same name - say dir.mnu for example. Some of these directories are not in the LabVIEW search path (e.g. My Documents\LabVIEW Data\....)

* You move the whole directory structure to a new location using the OS file manager.

* You try to reopen the LabVIEW project. LabVIEW realises that the project has moved because some files aren't where they were supposed to be, so LabVIEW starts searching for them. LabVIEW picks the first matching name it comes to. With a file like dir.mnu that's not going to be too difficult...

* LabVIEW repeats this several times for each missing dir.mnu file, each time locating the same wrong dir.mnu and happily changes the project file.

*You save the project file and then re-open it. LabVIEW now complains that the project file (or library) is corrupt because iit has two or more entries with the same URL.

The immediate problem here is that LabVIEW doesn't check for duplicating URLs when it 're-finds' a moved entry, thus allowing LabVIEW to corrupt its own project and library files. The underlying problem is that the re-finding algorithm isn't as clever as it needs to be. If the project/library files stored their own save path in the file then they could detect and calculate what the move 'vector' was and then before searching the standard search path for a matching name, could try looking for a new relative path. 9 times out of 10 a whole directory structure has been moved so that should relocate entries correctly. Again, a revision control system which can diff two files quikcly puts it right, but it should not be possible for LabVIEW to corrupt its own files except of course in the case of a power loss or program crash.

Link to comment

QUOTE (tcplomp @ May 17 2008, 01:03 PM)

I am using Subversion and the LabVIEW integrated tool at home via the PushOK plugin. The repository resides on a local Ubuntu server.

I have hardly a problem with the locked not-checked out items in the LV project.

I am going to enjoy this, at work I created a tool that checked all the files in the project, and reported those that were either old, not checked in or not in SCC. If anyone is interested in testing, PM me. I will try to get it up to CR standars (shouldn't be too hard though it contains express VIs).

Doe anyone know how to setup a https subversion repository on Linux?

Somehow I can't get it right.

Ton

Ton,

Since Jim feels the SVN model doesn't work with the check in/out model of the LabVIEW SCC integration, would you care to give your feeling on working with Push OK from within LabVIEW. Have you just learned to deal with the differences of the development models? Does this impact your productivity? Do you feel working with the plugin within LabVIEW helps you beyond using Tortoise SVN?

Link to comment
  • 3 weeks later...

Omar has raised up an important subject. Actually just today I encountered this issue with LabVIEW 8.5.1 where LabVIEW corrupted my class file because of a dependency issue where there was two classes of the same name in the project. It also appeared that LabVIEW file search algorithm that searches for missing files cannot locate class control inside class file but tries to locate it from a Windows folder instead. Naturally this fails and all class constants, controls and indicators in the project get broken. I didn't find any way to fix them so my project was ready for carbage bin. Luckily I do use SCC so only one day of work was wasted.

I think it's important not to think that corruptions cannot hapen with certain LabVIEW versions. The truth is that complicated software such as LabVIEW can always fail and developers should protect themselves against these failures.

Link to comment

QUOTE (Tomi Maila @ Jun 3 2008, 12:32 PM)

Actually just today I encountered this issue with LabVIEW 8.5.1 where LabVIEW corrupted my class file because of a dependency issue where there was two classes of the same name in the project.

It seems that the problem we had was much bigger than I thought. One class hierarchy keeps corrupting again and again. The origin of the problem is that I moved a highest class in a hierarchy into a lvlib library. As a result LabVIEW seems to have two different references to this class, one outside the lvlib and one inside the lvlib. It seems LabVIEW sometimes decides that the class is really not part of the lvlib and when it does so, all the hierarchy gets corrupted. I guess I've no other option but to go maybe a week back in my source code control regarding this hierarchy before I added the class to a lvlib. I hate that LabVIEW files are of binary format (including binary fields of class files) and that when something goes wrong with the compiler, there is no way to fix things manually or even investigate what is wrong manually to be able to report a bug. At the moment I cannot report a bug because I really don't know at which point LabVIEW screwed things up and how and I've no means of investigating it.

Link to comment

I just wanted to make sure that everyone on this thread is aware of some articles that might be useful concerning Source Code Control and LabVIEW. Here are a list of a few. Note that one is actually a wiki article on ni.com that is open for editing and community contribution.

Link to comment

QUOTE (tcplomp @ May 17 2008, 09:03 PM)

I am using Subversion and the LabVIEW integrated tool at home via the PushOK plugin. The repository resides on a local Ubuntu server.

I have hardly a problem with the locked not-checked out items in the LV project.

I am going to enjoy this, at work I created a tool that checked all the files in the project, and reported those that were either old, not checked in or not in SCC. If anyone is interested in testing, PM me. I will try to get it up to CR standars (shouldn't be too hard though it contains express VIs).

Doe anyone know how to setup a https subversion repository on Linux?

Somehow I can't get it right.

Ton

Yeah, add me to a list of poeple interested in getting SVN over HTTPS running on a linux machine......

Shane.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.