Jump to content

revision control and 3rd party add ons

Recommended Posts

Recently I was tangentially involved in a software management mess where the fact that a 3rd party LabVIEW add on was not in our source control (SVN) made it very difficult to build a new binary of a previous revision.

This particular add on has many revisions. It is a work in progress as we and the 3rd party do R&D on the application. In addition they are primarily PhD's in something other the Software Engineering. The code shows this and noteably the pinouts to the applications VIs change from revision to revision.

I think the OO jargon for this is Highly Coupled, meaning certain revision of our code work only with certain revisions of thier code.

We have a situation where instead of any developer being able to do a build at any time, only one or two machine can succesfully build this project.

I was reading other threads on this forum, specifically http://lavag.org/topic/13492-reuse-packages-and-scc/ and it looks like VIPM might be an answer. But I have specific questions about how it would work.

Apparently there is a VIPC file that would be committed to SVN or any SCC. When exporting, a developer would use this file in some way to verify that the right version of the packages are installed. Is this correct? What is the "some way"?

Will this process downgrade the 3rd party add on as needed?

Presumably also the VIPM would in some way make sure there were not two version of the packages in the VIPC, or do something else to prevent cross-linking?

So the way I imagine the use would be:

Checkout the code from a previous revision.

Update the 3rd party add ons to the correct version based on the VIPC file.

Build the binary and installer.

Delete working folder.

Or if a we needed a branch of a previous revision say 5.1 from 5.

Checkout version 5.

Update the 3rd party add ons to the correct version based on the VIPC file.

Make the required 5.1 revisions.

Check the VIPC for new dependencies.

Build/Test/Validate etc...

Commit changes including VIPC.

Is that right and does VIPM handle the package updates and dependency checks?


Link to comment

The VIPC will install the version that is needed. So if the VIPC calls for version 1.0 and VIPM sees that version 1.5 is installed, V1.5 will be uninstalled and V1.0 will then be installed. From my understanding, you shouldn't just delete files that VIPM installed. Let VIPM uninstall the files.

One of the beauties of VIPM is that packages can have dependencies so you can make sure you have all the code you need.

  • Like 1
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.

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.