Daklu Posted April 3, 2008 Report Share Posted April 3, 2008 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. Quote Link to comment
Justin Goeres Posted April 3, 2008 Report Share Posted April 3, 2008 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). Quote Link to comment
PJM_labview Posted April 4, 2008 Report Share Posted April 4, 2008 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 Quote Link to comment
Rolf Kalbermatter Posted April 4, 2008 Report Share Posted April 4, 2008 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 Quote Link to comment
Yair Posted April 4, 2008 Report Share Posted April 4, 2008 QUOTE (rolfk @ Apr 3 2008, 09:07 AM) You are able to configure LabVIEW to use a different user.lib path Really? How? Quote Link to comment
Ton Plomp Posted April 4, 2008 Report Share Posted April 4, 2008 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.