Do I need always need a shower?

[Fred Toewe]

Dear Listers,

I am trying to select an SCC tool for use in our very small company, but with a medium sized application of about 600 VIs and 40 MB of source code.  I have an issue or two that I don't seem to be able to find answers to in the discussion archives. 

1) Frequently, when I close the application, LV wants to save the top level VI and a multitude of Sub VIs, even though I have NOT explicitly edited them.  Why does LV do this?  And more importantly, can I stop it from doing this?  My concern is that my SCC tool is going to see a lot more changed files than I believe it should be seeing. 

2) With many(all?) SCC tools users can check out one or more files, perhaps even the entire application into a workspace of his choosing, make some changes, try out the code, and after he is satisfied, commit the changes back into the SCC repository.  Assuming that I use a unique file system directory for this workspace, LV is going to change almost every VI to reflect the location of the VIs in my workspace.  Again, this is very messy for the SCC tool to deal with. 

Are there tricks to work around these features of LV?  

Thanks,Fred

[mikeporter]

Question 1. Yes there is a way to get LV to stop doing what you have described. There are two settings under the Miscellaneous  options setting that handle the problem:

1. Treat read-only VIs as locked

2. Do not save automatic changes

Make sure both of these are checked. Next make sure all the VIs in your application are write protected, except for the ones that you are actively working on. I know this sounds very inconvenient, but its not really. In fact I have come to really like not having to worry about whether or not to save a changed VI.

Question 2: Directory structure will be a problem. The best thing to do is set up a dirtectory structure and everybody uses it whether they like it or not. This may sound fascist, but if you think about it the directory structure in the developement environment is what ensures that your code stays linked properly. Therefore my position has always been that the directory structure is part of what you are protecting.

In terms of the SCC tool itself, let me make a really strong recommendation in favor of Subversion.  Subversion is Open Source, free, works great, easy to set up, free, very powerful, secure--and did I mention free...

http://subversion.tigris.org/

Then to provide a nice Windows interface to your code repository, TortoiseSVN (also open source, free, etc, etc)

http://tortoisesvn.tigris.org/

Finally, to integrate it with LV Pro version, lvdiff (recently upgraded to provide enhanced features and improved error handling -- also free)

http://osdn.dl.sourceforge.net/sourceforge/meta-diff/lvdiff-2.2-win32.zip

If this is interesting I have a document I can post that covers how to install and configure things on the client end, Subversion's documentation describes how to setup the server.

Mike...

[altenbach]

---

@Fred Toewe wrote:

1) Frequently, when I close the application, LV wants to save the top level VI and a multitude of Sub VIs, even though I have NOT explicitly edited them.  Why does LV do this? 

---

One possible reason would be that your VIs were last saved in an older version. Loading them will convert them to the current LabVIEW version. If everything works, it is highly recommended to save them all in the current version for the following reasons:

1. The loading will be much faster because the conversion is no longer needed.
2. The VIs will run much more efficient. A freshly converted, but not yet saved, VI often has a much bigger memory footprint and can run several times slower.

(... and yes, you should probably use the shower once a day. Also don't forget to brush your teeth and use deodorant ;))

[Fred Toewe]

Mike,

Thanks for the answers. Your help is wonderful.  I've seen your suggestion of Subversion etc. before and am in the process of trying it now.  Do you have a vested interest?

I was contemplating using a mapped drive (always the same letter) to point to the top of the unique workspace in order to prevent LV from seeing the new directory name but your suggestion of edicting its name would work too (if I can get my boss to use it.) 

On your suggestion to use the two Miscellaneous Option settings, must I set these individually for each of the roughly 600 VIs?  Can they be set programmatically in LV or Perl or ??

Thanks and Cheers,

Fred

[Fred Toewe]

Altenbach,

No, these VIs are all from the same version of LV (7.1), but thanks for the idea.

Cheers, Fred

[mikeporter]

No vested interest in Subversion, other than it's just really good. Of course lvdiff is another matter. If you don't have the latest update you really should get it because the guy who modified it last really did a great job...  

The way I work with Subversion is that I have basically two working copies on my machine: the application specific code in a directory off my C or D drive, and the user.lib directory containing all my common code. Within those directories I have a fixed structure of sub directories. In terms of your boss, just explain that conforming to a few standards will, "...impose a degree of discipline that will make everyone better at what they do". Then throw in a couple buzzwords like "enhanced ROI" or "working smarter, not harder",  and you'll have it made...

... or you just could threaten to break his fingers if he mucks something up...

Concerning the settings, those are global LV settings. In other words, they deal with how LV interacts with files. All you have to do to the individual files is make sure they are write protected, and the easiest way to do that is write a small utility that goes through and and sets them all. Attached is a VI I write to recursively write-protect or un-write-protect all the files with the specified extensions in a directory.

Mike..

Message Edited by mikeporter on 08-29-2005 10:16 PM

[mikeporter]

oops, didn't attach the file...

Mike..

[Fred Toewe]

Mike,

Thanks again for your help.  It's a pleasure...

Cheers, Fred