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 post
Share on other sites

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 post
Share on other sites

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.

  • Similar Content

    • By Francois Normandin
      As I've reported in the UI Tools support page, I've started migrating the open source code I still have on bitbucket (Mercurial-based repos) to Github.
      I didn't think that it might be worth a specific topic until @LogMAN mentioned it. Personally, I'm moving my code to Github in the process. I know there are some reports of Hg-to-Git transitions not going so well when using sub-repositories, so please share your migration experience if you've had to jump into some hoops to get it done!
      For all of you who still use Mercurial and host your open source and/or enterprise repos on Bitbucket, this blog post is worth reading:
    • By JeremyMarquis
      I am playing with GitHub as a possible replacement for our current SCC tool.
      Do you guys use Git or GitHub?  What client app do you use?  Any recommendations?
      I am specifically leaving the topic scope open, so feel free to praise/rant/headscratch.
    • By JackDunaway
      While creating a new a new repo in GitHub, I noticed there is not a template .gitignore for LabVIEW -- let's make one!
      After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore.
      So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore
      Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request.
      Here's the contents of the file right now:
      # http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/lv_file_extensions/*.aliases*.lvlps How can this be improved?
    • By VideoB
      Hi all,
      I've recently started using Subverion + TortoiseSVN to manage the source code of LabVIEW projects and I'm now getting to the point where I don't really know what I should do ; untill I had no banches and just revisions and a couple of tags for shipped versions I could handle it.
      Now I need to go further than that and manage a large project that consist in an EXE and 3 plugins. The EXE will be shipped to many customers and each customer will have different "flavours" of the plugins.
      I'm not feeling confortable enough with SCC usage to decide how to manage this scenario. Multiple repos? Sub-repos (does it exist?), one repo and 1 branch per customer?
      The whole source code sums up to about 2000 VIs.
      The EXE and the plugins have subVIs in common (some that are user.lib and some that are part of the project).
      Any advice greatly appriciated.
    • By JamesMc86
      I'm looking for some advice from anyone who has been using mercurial with LabVIEW.
      Firstly I have just been trying some branching and merging. After a merge, having been configured for merge using https://bitbucket.or...iew-integration I see some .orig files getting left in the repository. Is this a failing on LabVIEWmerge.exe to clean it up or is it the way mercurial works?
      I am interested in the DVCS camps because of merging. I currently use SVN, primarily as a lone developer. I like not having to maintain a separate central repo and the improved merging, primarily from the point of having sandbox branches. I like that in Git, if I have an experimental branch that doesn't work out I can delete it. Is there a similar workflow with bookmarks that can be achieved or am I going to end up with a load of bookmarks littered around the place?
      I liked that Mercurial integrates better with Windows and is a simpler way to learn DVCS than Git, but I do also like the look of branching in Git and think the extra flexibility may be a killer feature. That said my general opinion when you get these 'holy wars' is that there is probably no real difference between them, else people wouldn't be arguing so much over minor details!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.