Archiving code strategies?

[Daklu]

Currently I'm going through all our Labview tools created over the last 2 years and archiving them in our source control system. Most of them are simply vi trees dumped in a single directory with many outdated and unused vis present. I'm switching them all over to 8.5 projects so I can create build specifications to ease my task.

My questions are:

• When storing projects in source control, what do you include as part of your project as opposed to leaving under dependencies? VIs from user.lib? instr.lib? vi.lib? DLLs?
  
• When you check in code do you create a zip build and check that in? (As near as I can tell you need to do that to collect the vis not in your project directory, unless you want to find them and add them all manually.)
  
• Does your strategy change when you are checking in code for a project currently under dev versus closing a project?
  

Many of these projects are being archived and if they are ever checked out again it's likely it will be by a different user on a different computer with different addons installed, etc.

[Justin Goeres]

QUOTE (Daklu @ Apr 2 2008, 01:16 PM)

• When storing projects in source control, what do you include as part of your project as opposed to leaving under dependencies? VIs from user.lib? instr.lib? vi.lib? DLLs?
  

I never put my vi.lib directory under source control. My rationale for that is that LabVIEW manages vi.lib itself (toolkits, updates, etc.) and nothing good can come of any contribution I make to it.

In the past I had parts of my user.lib under source control, but it was a pain to deal with and I felt really uncomfortable having SVN-managed files hanging out in a subdirectory of Program Files. So I stopped. I do have elements of my user.lib in SVN, but I export them into user.lib instead of checking them out.

QUOTE

• When you check in code do you create a zip build and check that in? (As near as I can tell you need to do that to collect the vis not in your project directory, unless you want to find them and add them all manually.)
  
  

The answer to this question sort of depends on how your source is organized on disk. In my case, I keep all the non-vi.lib and non-user.lib VIs for each project arranged below a single parent directory. Then I check in that entire directory (and all subdirectories) and treat it as the repository branch for a given project.

I don't recommend checking in a zipped set of files, because if you do that you lose the ability to version each file individually. It short circuits one of the main features of source control.

QUOTE

• Does your strategy change when you are checking in code for a project currently under dev versus closing a project?
  
  

No. I use the standard SVN trunk/branches/tags arrangement. So all my checkins go into trunk (or into a branch if I'm working on a branch). Then when I do a release or close a project, I copy the current trunk (or branch) to a new subdirectory under tags. Because of the magic of SVN, that gives you a trivial way to create a named snapshot (tag) of your tree, and uses virtually zero extra disk space.

QUOTE

Many of these projects are being archived and if they are ever checked out again it's likely it will be by a different user on a different computer with different addons installed, etc.

Because of the nature of LabVIEW's vi.lib & user.lib directories, I don't know of a catch-all solution to that. One thing I do to mitigate the problem is I build a Package Configuration file for each project and store it in the trunk of the project it belongs to. That way when anybody checks out that trunk, they can apply the package configuration to set the libraries up correctly (obviously this only works for libraries that are managed by VIPM to begin with).

[PJM_labview]

One of the thing to add to Justin comment (beside using VIPM which is a great idea :thumbup: [and this is what we do of course]) is that in my opinion, as a general rule, you should not "archive" in a LV version different than the one the VIs were created. If (or when) a user has to go back to work on this project, the LV upgrade you just made has introduced unknowns (and potential new LabVIEW bug) in the project. If the released software product has been made with LabVIEW x.x then "archive" the code in LabVIEW x.x version.

PJM

[Rolf Kalbermatter]

QUOTE (Justin Goeres @ Apr 2 2008, 05:47 PM)

In the past I had parts of my user.lib under source control, but it was a pain to deal with and I felt really uncomfortable having SVN-managed files hanging out in a subdirectory of Program Files. So I stopped. I do have elements of my user.lib in SVN, but I export them into user.lib instead of checking them out.

You are able to configure LabVIEW to use a different user.lib path and upcomgin versions of LabVIEW while not going to do away with the standard LabVIEW internal user.lib will likely add another user.lib in your user profile directory and those two will be merged on startup.

Rolf Kalbermatter

[Yair]

QUOTE (rolfk @ Apr 3 2008, 09:07 AM)

You are able to configure LabVIEW to use a different user.lib path

Really? How?

[Ton Plomp]

QUOTE (Yen @ Apr 3 2008, 07:24 PM)

Really? How?

I have seen (and used) this in LabVIEW 8.0.

It sucked.

I think that's the reason NI removed it (or I can't find it anymore in LabVIEW 8.5)

Ton