Source Code Control Basics

[K-node]

Most of our projects in the past have been single developer based. We are now trying to get a common code base on new projects and there will be multiple developers. The development is almost all LVOOP, but I am not sure that really matters. Also, it is likely we will be using TFS but I don't think this matters for my initial questions at least.

I played around with Tortoise/SVN and the file based repository and had one other developer along for the ride, so if you want to respond with that as a reference, that is OK too.

This first question is a very basic one. Sometimes a small change in a VI has an incredible echo in other VIs. I am not talking about changing an API for a method. Clearly that would require callers to be updated. I am remembering a change to say the icon of a VI and all of a sudden here is a huge impact. There may be other things. I guess my question is LabVIEW retains the interdependencies, how do you get a handle on these changes as they might impact another developer of a 'somehow' related module?

[Yair]

That's because LV recompiles the machine code in certain cases (such as changing the way you move data through the VI) and the machine code is saved inside VIs. One way of handling this in 2010 and later is setting the separate compiled code check box in each VI's properties, but I understand that sometimes has bug-producing behavior.

You're probably also going to want to read this - https://decibel.ni.com/content/blogs/Matthew.Kelton/2011/09/30/labview-and-versionsource-code-control--introduction

[candidus]

Talk to each other. I'm serious.

Team meetings are very important to minimize the risk of painful surprises. Decide who is working on which part of the code. If you have to change an interdependent module, talk to the developer who is responsible for that code.

[asbo]

candidus makes a very good point, and on top of that, encourage developers to be vigilant about locking VIs their modifying and subsequently locking VIs which may be affected by those changes. In multi-developer projects, it's pretty normal that we don't do a re-save for all recompiled VIs for lengths at a time. Probably should, since this adds to everyone's load time when the disk version has to be recompiled every time, but so long as there's no manual changes to the VI, I don't go out of my way to make sure all the interdependent stuff gets resaved. Especially in large projects, it can be a tedious effort to do so.

[dannyt]

I would move up to LabVIEW 2010, the separate source & compile code feature is great I would say a must for team working situations. I have been working with it for a couple of years with no problems.

I would also agree with candidus, planning an communication are key for team working.

[K-node]

Thanks for all of your replies. It seems that everyone favors communications. Not a problem as all of us are in neighboring offices, and with the exception of me, there are no prima donna's . Also, as our common code matures, we won't run into each other as much - I hope.

I will explore the separation of source and compiled code. We are developing under LV2011 now so hopefully any previous woes from this capability are minimized. I assume that you only put the VI under source control, not the viobj file.

I am so used to hitting 'Save all' at this point, that would be tough to stop, but that is probably because I develop opn my own.

Yair, thanks for the link, I am still reading this. Good stuff.

It seems that the MSSCCI for TFS requires the licensed client for an install. Not a problem for me as I have an MSDN subscription, but I am the only one among my fellow LabVIEW developers at this point. There are four others that have LV licenses, plus at least one in another group. So, we are still working out that issue.

It just so happens that our NJ LabVIEW Users Group is having someone talk about SCC this Thursday.

I got a little link-happy in this post.

Thanks again!

[Daklu]

At my previous job we had multiple developers working on projects and we used TFS. One particular project had grown out of control and it was really easy to end up with conflicts when trying to check stuff in. I've since picked up some habits that help keep everyone in their own sandbox.

1. Set the options "Treat read-only VIs as locked" and "Do not save automatic changes." This is one advantage TFS and similar systems have over SVN. Since TFS uses the read-only flag to determine whether or not a file is checked out it's very difficult to accidentally change a VI.

2. Use project libraries to separate your application into components and put all vis in a library. That will reduce the number of changes to the .lvproj file and help prevent collisions. If vis are not in a library the .lvproj file has to maintain information about its location. When a vi is in a library, the library maintains the location information for all its members, meaning the .lvproj file doesn't get changed as often.

3. Make sure only one developer is working on any given library at a time. Don't allow anyone else to make changes to that library.

4. Don't nest project libraries. Putting classes in an lvlib is good, but an lvlib in an lvlib doesn't work so well. If you have hierarchical libraries you can use dot notation naming conventions on your library names.

[Tim_S]

1. Set the options "Treat read-only VIs as locked" and "Do not save automatic changes." This is one advantage TFS and similar systems have over SVN. Since TFS uses the read-only flag to determine whether or not a file is checked out it's very difficult to accidentally change a VI.

SVN does (can?) also set the read-only flag; we have SVN set up that way.

[asbo]

SVN does (can?) also set the read-only flag; we have SVN set up that way.

Yep, this is the need-lock property. A must-have for non-merge-able files. I can't tell you off-hand how to make every new file inherit the property, but it's possible.

[Tim_S]

Yep, this is the need-lock property. A must-have for non-merge-able files. I can't tell you off-hand how to make every new file inherit the property, but it's possible.

The guy who set up ours years ago made the repository/server-side default with that property. I'm sure could figure it out if RTFM.

[Daklu]

SVN does (can?) also set the read-only flag; we have SVN set up that way.

I didn't know that. Thanks for the tip.

[PaulL]

4. Don't nest project libraries. Putting classes in an lvlib is good, but an lvlib in an lvlib doesn't work so well. If you have hierarchical libraries you can use dot notation naming conventions on your library names.

It's good to see you commenting on the forum again!!!

I'm not sure I quite agree on #4. I would rather say use nested .lvlibs where this is appropriate. (We don't do this often but we have cases where this seems appropriate.) What is your concern with version control and nested project libraries? (I do think that only one developer should be working on the larger library at a time.)

I certainly agree with 2 and 3. We don't do 1 (with SVN) but we don't see any issues either.

[Daklu]

What is your concern with version control and nested project libraries?

My original thought was that it closes off a larger section of code to multiple developers. In hindsight, it's not so much that I have a problem with version control and nested libraries, it's more that nested libraries in general don't serve any purpose for me.

I use project libraries to define software components. Usually I want the components to be loosely coupled to other components to facilitate reuse. The only reason I can think of for nesting libraries is for organizational purposes when a component is made of several subcomponents. However, by combining multiple subcomponents into a single library I can no longer use a subcomponent in another app without dragging all the other subcomponents along with it. I retain more flexibility by not nesting them.

Incidentally, using a dot naming convention for project libraries is something AQ suggested to me... oh... four years ago or so when I first started crying about namespaces. I resisted for a while but, as is usually the case, I came to understand how his suggestion simplified things.

[crelf]

Yep, this is the need-lock property. A must-have for non-merge-able files. I can't tell you off-hand how to make every new file inherit the property, but it's possible.

it's a pretty straight forward change to each client's config: http://www.orcaware....k-modify-unlock We have a script that runs from the server side on client logon that checks for and updates these props.

Incidentally, using a dot naming convention for project libraries is something AQ suggested to me... oh... four years ago or so when I first started crying about namespaces. I resisted for a while but, as is usually the case, I came to understand how his suggestion simplified things.

I cop a lot of crap around here for dot namespacing almost *everything* (especially when it comes to reuse components and anything OO), but I try to rise above it all. After all, it's difficult to fly like an eagle when you're surrounded by turkeys. And I mean that in the most respectful and positive way.

PS: when you dot namespace, do you do it in forward or reverse? I remember reverse was used a lot in the military (eg: shirt.ShortSleeve.Blue.Men's as opposed to Men's.Blue.ShortSleeve.Shirt). I also get my ass into trouble if I don't properly design stuff like this, because my namespaces turn out to be in the wrong order, or singular when they should have been plural, etc.

[Daklu]

After all, it's difficult to fly like an eagle when you're surrounded by turkeys.

Yeah, but come Thanksgiving you're fat and happy while they're having nervous breakdowns.

PS: when you dot namespace, do you do it in forward or reverse?

I do it forward. It sorts better and I've never been in the military.

[K-node]

Couple of questions on separating compiled code...

In LV Help on this topic, it states:

• To prepare VIs in source control to be upgraded to a new version of LabVIEW—If you separate compiled code from VIs, you do not have to check out the VIs from source control to upgrade them to a new version of LabVIEW.
  

Does this mean I don't need to store the reusable, compiled code separated VIs under multiple locations for each LV version in a repository?

Is this a good idea?