Team Based Development and Source Code Control Presentation Material

[Elijah_K]

These slides explain best-practices for application management for team-based development using integrated tools like the Project Explorer and SCC.

[TiTou]

Very good ppt!

I ha ve a question about the LV project organization, you say (p14) "organization should reflect hierarchy on disk". Could you give more details/advice about what NI recommends ?

Do you mean auto-populated folder should be used on the root directory or do you mean we should just have the same hierarchy of folder on the disk and in the project explorer?

[Ben]

"organization should reflect hierarchy on disk".

Unless I misunderstand (I can't view the presentation since I don't have the new MS stuff) I have to disagree strongly when talking about LVOOP.

LVOOP wants all of the VIs for the class to live in a floder that sits next to the class. If you start getting creative with the floders you will confuse LVOOP.

Within each LVOOP class I used virtual folders to seprate public private and proected methods and often use and even greater degree or organization. So in that case alone the origanization should not match the disk structure.

And here is a complication associated with the idea that org matches disk.

Say you have seperate floders for private public etc methods and durring development you find that a method has to be changed from private to public. TO do that you would have to save the method to the new folder BUT the old one is till where it ws on the disk. SO this is another case where trying to match organization with file structure is a bad idea.

If I am mis-understanding please tell me what I am missing.

I try my best to enusre that published "standard practices" for LV are correct because these often develop into "gospel" so lets get this right the first time. I don't want the advanced users to have their code questioned because they exploited a feature that someone decided should not be used.

Take care,

Ben

[Elijah_K]

Ben makes an excellent point.  As with most of the topics covered in this presentation, there are a number of caveats and excepetions to the recommendations made.  As the presentation points out, the use of Project Libraries and Classes should not be combined with autopopulating (AP) folders.  However, I think most would agree that it benefits their own sanity to keep the hierarchy in the Project as similar as possible to the organization on disk, even if AP Folders are not in use.

Perhaps just keeping the top level folder structure the same is enough for applications that rely heavily on classes.  Thoughts Ben?

[tst]

I feel that the project does NOT need to have all files in the project view, only the ones you want easy access to. You can get to the others by going through the hierarcy, using the dependencies section or the files tab. As such, the project view does not need to have a 1-to-1 relation to the folder structure, although it usually makes sense to keep it the same with the folders which are in the project.

We had a discussion about this here.

[Elijah_K]

In order to take advantage of several of the Project features it's to your benefit to add everything.  By doing so, LabVIEW is smart enough to tell you if you're using a dependency other than the one you intended.  It also helps when it comes time to build a source distribution, or if you want to use other tools like the integrated diff functionality.

Ultimately, it's all a matter of personal preference.  These are meant to serve as guidelines for those in search of tips.

[Ben]

The option to "find in Folder view" goes a long way in disconnecting the logical presentation of the project from the physical location of disk.

As to the question how to organize on disk? There are two answers to that Q. If you are preparing for a certification exam, use the NI standards since starting a fight over which standard to follow in the middle of an exam is a bad idea (that is what forums like this one are for).

When not taking an exam?

I organize my files on disk such that I can do a "Source Distribution - New Location - preserve hierarchy" and wind up with a nice little set of folders that I can drop in a new project.

Closing thoughts:

The two view available in the Project Explorer has enabled us to present our projects in more than one form. To define one of the views as a form of the other limits our ability to communicate to our readers. Analogy: If drafting had similar rules that limited drawing to only top, front and side views, we would be forced to piece together the parts into a mental model of for example, a cube. If on the other hand they where allowed to present the information using a perspective view, the information that is lost in a perspective view are more than made for by the "Big Picture" that shows how the parts work together.

Just my two cents,

Ben

[tst]

By doing so, LabVIEW is smart enough to tell you if you're using a dependency other than the one you intended.

I think this is the first time I hear a concrete argument for this - explicitly forcing dependencies, although the question is what happens when you add a VI to a project which has a conflicting item. I never really delved into the dialog which you get because it's too indimidating and I believe you usually only get a single enabled option.

I can't say I understand the diff and source dist arguments, though. I would expect that you should still be able to use them even if you don't explictly include items in the project.

These are meant to serve as guidelines for those in search of tips.

You should note that many people probably take this as gospel unless this is explicitly stated.

[Omar_Mussa]

For interested parties, we at JKI have just released a new TortoiseSVN tool that makes it easier to integrate TortoiseSVN/Subversion with LabVIEW using the update/commit model.