maintaining code in two labview versions

[RTSLVU]

We have a huge code base written in Labview 5.11

I am the first one to get an upgrade (now at 8.2)

So I have to maintain a lot of code in 5.11 since I do not have the time to convert it all to 8.2 and nobody else has 8.2 yet anyway.

I have 5.11 and 8.2 installed on the same computer and have the code seperated into two different directories.

The problem I have is if I open a vi in Labview 5.11 then later go to open a vi in Labview 8.2. Labview 8.2 will default to the last directory 5.11 was using and I end up opening an old file or worse yet saving a sub vi in 8.2 but over writing the 5.11. Then finding I broke several other 5.11 vi's that use this sub vi.

Is there any way to set the base directory that Labview looks in when you open a vi?

What is the best way to maintain two different code bases?

[TCPlomp]

The best (and safest) way is to get two usb-drives and just connect one of them

Then LV has a method for reading the version of a file (without actually opening it), you can automatically load it with the version you want.
Dataact has a special program for this just 29$


About the last folder issue. This is something of windows that stores the last folder to an executable name (LabVIEW.exe) so you can rename your labview to labview51.exe and labview82.exe

Ton

Message Edited by TonP on 05-04-2007 07:15 PM

[CS]

Have you considered using  a virtualized development environment with a program such as VMWare?

Tomi Maila presented this idea on his blog "ExpressionFlow".

http://expressionflow.com/

[mikeporter]

You could also use a source-code control package like Subversion to keep things straight. You could then have two repositories one for V5 code and one for V8. When you want to work on a particular version, you would simply switch your working copy to that repository.

You could also keep all your VIs set to read-only, this would require you to consiously decide to save a particular file.

Mike...

[tst]

Welcome back, Mike. (oh, I already said that  )

Just wanted to say that I'm in the process of reading a Subversion usage document you posted once and seeing if I can get any useful information from it.
Thanks for that.

[mikeporter]

Thanks for the welcome (both of them),

In terms of Subversion, I have gotten to the point that I can't imagine working in an environment where I don't have a good source code control system backing me up. I think that a lot of the reason that people resist SCC is that they have had bad experiences with a bad product like Visual Source Safe. If you have any specific questions feel free to ask...

Mike...

[tst]

---

@mikeporter wrote:
I think that a lot of the reason that people resist SCC is that they have had bad experiences with a bad product like Visual Source Safe.

---

Aaaahhhh! The horror, the horror.

I do have to work with VSS at a client's and, while it works out nicely for their .NET guys, it's a pain for me. Nowhere near as convenient and fast as SVN.

I tried using the built-in support, but when I found out it only works on a single VI basis, I switched to working with the file hierarchy, but that's also a pain, because adding a file hierarchy in the first place is tricky (you have to drag and drop it from Explorer) and it doesn't recognize new files automatically. Oh, and it's sloooow.

I just hope I never need to actually revert my code.

BTW, SVN and TSVN also have their own shortcomings - no way to set properties to single files, no convenient way to ignore checked in files, setting a property to hierarchy removes the existing properties in lower levels of the hierarchy, no elegant way to immediately start versioning existing files, no elegant method of making choices of how to handle some conflicts, etc.

But in general, it's great.

P.S. What do you do for managing the DB (managing users and passwords, backing up, etc.)? Do you use the SVN commands or did you write some wrapper UI VIs around that?
I'm still in the process of finalizing that aspect here (and I need to finish writing my own internal use document), so I would like to hear any tips you might have.

[mikeporter]

Hey there...

First of all, concerning your "PS" I'm afraid I can't really tell you how the password stuff is managed because the repository resides on Red-Hat Linux box that is managed by our IT organization, so they handle all the stuff like backups and security - which actually is one of the advantages. We don't have to figure out how to do all that stuff ourselves... The main thing was to train our developers to log-out of TortoiseSVN when they are done working on a system other than their own personal PC.

In terms of the shortcomings you mentioned, I'm not sure what you mean. A little more detail?

Mike...

[tst]

Some examples, based on my previous points:

• When you create a new repository based on existing files, you need to import the files, move\delete them and then check out. This can be annoying when you have a lot of data, although you only need to do it once for each repository.
• Suppose you have configuration files as part of your hierarchy. Suppose further that the configuration files hold the program configuration as well as the running config (window positions, MRU lists, etc.). You can't ignore the files, since you need them, but each time the program is run, the file will be changed and you will need to commit or revert it. Collabnet suggests that you should use templates for this kind of scenario, but these don't fit properly.
• Suppose you did decide to split up the program configuration and user configuration into seperate files, so that you can now set the repository to ignore the user config files on the directories where you changed this. Then, you realize something else - Windows creates a thumbs.db file in each directory where you have images and updates that file whenever those images change. You could try to go to the top level directory and set the entire hierarchy to ignore files called thumbs.db, but there are two problems with that:
• Changing the property will propogate down and overwrite your previously defined properties (at least when you do it in TSVN).
• You can't actually ignore the files, since they're already versioned. You have to delete them and only then can you ignore them.
• You try to update a file over an unversioned file. TSVN will make its "annoying sound" and stop instead of giving you a dialog allowing you to choose between different options.

Again, these are mostly relatively minor and can be worked around, but they are annoying. I still think that SVN is great just like I think LV is great even though the Value Change event is at the bottom of the events list in a badly sized dialog.

Another P.S. Thanks for LVDiff. I'm using it (with some minor modification of my own) and finding it very useful.
My crystal ball tells me that it might need a little brother soon enough.

[mikeporter]

Yes, I see what you mean now... Except I haven't seen the behaviour that you mention in your third bullet. Admitedly I haven't spent a lot of time monitoring it, but the only time I have noticed that thumbnails.db file being created is if you have the view for the directory set to "Thumbnails".

Mike...