Jump to content

Questions Regarding SVN and Project File Organization

Recommended Posts

Hi all,

I am fairly new to Labview development.  I want to implement revision control software (SVN in particular) to my workplace.  Before I can do this, I need to prove the concept and usefulness of the SVN application for us.  I have used SVN in some degree in the past, and noticed tortoiseSVN integration with Labview via the TSVN Toolkit.  I have a few questions regarding SVN and how I should organize my project files, in particular when using SVN.

File organization has been a particular gray area for me in Labview, unlike linking my libraries and specifying their locations I don't seem to quite have that control in Labview.  This issue is somewhat more exacerbated (or at least so I think) when I began using SVN.  Let me explain: Using the TSVN toolkit it sees that my entire class (which was developed in a separate directory - then linked in) is not sourced and revisioned.  This is also the case for several other libraries which I have borrowed or developed myself.  I have two primary questions regarding this.

The first - How does SVN add/commit these project files when they are not present within the project directory itself?  In fact I have created a separate repo for the class which I use to maintain that code.

The second - Is my file organizational design fundamentally flawed? Especially in the context of SVN?  What are some good organizational tips/ schemes (when using SVN) which would help me for future projects in avoiding issues such as this? 


A  less pressing question:

How well does the "merge" functioning work with the Labview VIs?  Remember I am do not have the most experience with SVN - it is my understanding that merge basically would merge changes I have made back with changes by other devs to the file along the main trunk(?).  


Thanks in advance.


Link to comment

No advice in the merge topic other than don't do it.  LabVIEW files are obviously binary in nature, and merge doesn't work well.  That being said some developers do implement a merge paradigm in LabVIEW and SVN.  LabVIEW has some file compare tools to see what changes have changed from one revision to another but I have no idea how well they work in a SCC.

SVN also can work in the Lock/Commit paradigm where VI files will be read-only until you have requested a lock from the server (look into needs-lock).  At which point you can edit the file and commit changes but no one else can.  If they attempt to get a lock SVN will say what user has the lock at which point you can ask them if they are still working on it.  Dividing up the application into code modules and assigning a developer their set of code usually minimizes the number of times you need to ask a developer about their part of the code, but it happens.

BTW I just suggest Tortoise SVN, which is the Windows Explorer extension.  If the file is read-only, LabVIEW will complain when you go to save, at which point a save dialog will come up.  From here you can right click the file and choose to get the lock, cancel the save dialog, and resave the VI (which shouldn't be read-only any more).  Some other toolkits help in things like a rename.

If you need to rename or move a file, then LabVIEW needs to be aware of the change (the project and files that link to it) and SVN needs to know it was renamed.  Some of these 3rd party tools like ViewPoint can do this but it is generally a pain.

As for file structure.  Code that is reuse, and not part of the project needs to be found by a single common location.  My advice is either the vi.lib or user.lib.  You take your common code, package it up with VIPM, and then have all your project code link to that common stuff there.  The source to the VIPM packages can be in a separate reuse SVN repository, but your code only ever links to the code from the installed location of user.lib.  It can be more steps to make changes, since instead of changing the code in user.lib you should change the package source, build a new package, release it, then install it.  Where previously you would be just used to editing the VIs as they are.  Another alternative I've heard of but am less of a fan of, is to checkout the reuse repository to your user.lib.  Then you can edit the reuse source and commit it back to SCC.  This has advantages and disadvantages of course

  • Like 1
Link to comment

Hooovahh,  thanks for the response.

When you say "I just suggest Tortoise SVN" by that do you mean tortoiseSVN versus other client side options or are you saying do not use the TSVN Toolkit from viewpoint (http://sine.ni.com/nips/cds/view/p/lang/en/nid/211524)?

While merge is the ideal, we would likely use the lock/commit scheme, but a concern is, Dev. A is working on a control or enum that cascades down to multiple VIs will that developer need to lock out all of those VIs from Dev. B?  It seems like the best way to avoid lockout issues is with branches but my concern is how well these branches can be committed back to the main trunk for deployment, particularly for Labview.

Again, thanks for the response, a lot of good information and advice.


Link to comment

I was suggesting just use the TortoiseSVN client, and not bother with any other toolkits.  JKI and ViewPoint make a couple and while they work fine, I generally just am more comfortable using Windows Explorer.  That is again for all things other than a rename, which I have used ViewPoint for, but I try to just avoid renaming unless necessary.

As for the lock commit of controls.  One thing that helps with this (but I'm not sure eliminates it) is making sure all VIs are set to "Separate compiled code from source file".  There is some code that will perform this on a project or folder of VIs, here is a start.  This should be on for all SCC options for a couple reasons.  I still think that if Dev A edits a type def control, then all the other VIs that use it will have unsaved changes for Dev A.  But if Dev B is working on a VI that uses that control, then Dev A has no obligation to update that VI, save, and commit it.  They just have to edit the control and commit.  Once Dev B does an update and gets the new control, the VI they can edit will have unsaved changes at which point they should save it and commit.  In practice this ends up with alot of "Continue Saving Without Prompts" for Dev A (since they can't get locks on those VIs which are effected by the control edit

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.

  • Similar Content

    • By rharmon@sandia.gov
      So I spent much of the afternoon looking over postings here on Source Control Software and LabVIEW. I must say I came away discouraged.
      I've been programming LabVIEW for over 20 years in a single one technician lab and never really needed any stinking source control. Well now that's not the case. But thought I'd just read some posts, determine what everyone else likes and be done!!!!! That didn't work out for me ether... Seems nobody really likes source control after all. Or at least there are issues with just about every option.
      So here is my situation. I'm still the single labVIEW developer on a project. But the project requires a more structured source control environment. So I'm looking for source control that works flawlessly within LabVIEW and  is easy to use, I'm Using latest versions of LabVIEW.  
      Since most of the posts I read today are from years back, I'm hoping things have really improved in the last couple years and you guys are happy as a lark with your source control environment.
      If you could take a minute and tell me:
      1. What type of source control software you are using?
      2. You love it, or hate it?
      3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else
      4. Pro's and Con's of the source control you are using?
      5. Just how often does your source control software screw up and cause you major pain?
      Thank you in advance.
      Bob Harmon
    • By Tim_S
      Our IT department is rolling out a SCC package called Version Dog to our site. Looking a the website, it looks to be geared for PLCs but down in the documentation it mentions LabVIEW. Has anyone heard of this before? Used it? Have opinions on it? Not impressed by the amount of openly available non-fluff information on the website.
      We do have a SVN server running, however the network changes from when the current owners took over have FUBAR our ability to connect to SVN from our desk. This appears to be a much needed effort to version control the PLC programs (long overdue) and an attempt to close out IT work tickets that are many years old.
      Thanks in advance for any replies.
    • 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?
  • Create New...

Important Information

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