Managing *.lvproj in Source Code Control

[#1]

I have a basic question regarding SCC and the *.lvproj file when multiple developers are involved. In the NI doc, <http://decibel.ni.com/content/docs/DOC-1681> a paragraph states,

"Adding or renaming files in a Project will alter the contents of the

*.lvproj file, which requires checking it out and submitting a new

revision to the SCC provider. Since these changes affect all

developers using the *.lvproj file, it is inadvisable to make any

modifications during development. If changes must be made, they

should only be made by one user at a time, and all other developers

should get the latest revision of this file as soon as changes are

complete. However, there are alternatives when this is not possible."

Does this mean that the simple act of creating a new VI requires the following procedure:

1. The creator of the new VI adds it to his *.lvproj

2. He checks *.lvproj back in to the depot

3. All other developers will need to close down, re- checkout the *.lvproj, and relaunch.

That seems awkward. Instead, it seems like working without lvproj open is actually simpler because the next time it's opened it discovers the new subVIs (it will of course require a full update at that time). So I'm looking for recommendations on this.

[Elijah_K]

Are your files locked for editing unless checked out, or do you keep all the files checked out during development?

[#3]

The current plan is locked unless checked out.

[Elijah_K]

Many people, especially those that use Subversion, keep all files unlocked, even if they are not checked out in order to avoid some of these probelms.  I know that internally, we frequently do this with our applications that are stored in Perforce.

However, I understand that this may not be an option, so their are some other practices I've seen implemented to avoid this.  To answer your question, yes, by default if you add a VI this modifies the XML in the *.lvproj file, which would then require checking it out, saving it, checking in the change and then any other developers are your team would have to pull down the modification.

Here are some alternative ideas:

1. Use autopopulating folders and do not save modifications to the lvproj file on a regular basis.  By doing so, the project will automatically be populated any new VIs that have been added
2. (This is more elegant) Use Project libraries to encapsulate different pieces of functionality.  The Project library contains information about it's contents, but the Project file (lvproj) only contains information about the Project library.  This means that you can make modifications or add VIs to the Project library without modifying the Project file.  The success of this method depends upon having well defined sections of an applicaiton for different developers to work on.  It also encourages the good practices of defining APIs for separate sections of code to call.
3. Finally, you can use separate lvproj files with common dependencies.

I'd be curious to know how these methods work or if anyone else has ever tried any of them.

[tstahl]

Our primary code consists of over 10,000 files (not including user.lib or vi.lib).  An application of this size can be broken down into sub-applications, which we put into 10 projects.  Some of the sub-applications are dependant on lower level sub-applications (such as error handling).  Breaking into sub-applications makes testing and debug easier.  The original structure was developed in LabVIEW 6.1 and has grown and evolved with versions of LabVIEW; I would make different structure choices, however I believe the basic concept is good: break the application into (reusable?) sub-components and develop those independently, test them independently and validate them independently.  Objects and libraries can be used to encapsulate code separate from an overall project.

The practice of keeping files unlocked is the recipe for a nightmare and huge numbers of man-hours later.  Developer A starts making changes on files that Developer B is working on with neither knowing.  In the end, one's changes get checked in to SCC with means the other's dependant code may not work.  All files both developers worked with become suspect once this is found (if they can remember which files they edited!).  The process of determining what changes were made in which files and reconciling these can take man-weeks.  This wound up happening with my company when we contracted some work out and the contractor could not get into our SCC within the timeframe of the contract.

Tim

[PaulLotz]

Up to this point we haven't locked files (with Subversion), but we are reconsidering this strategy as we are sharing more code now.  Not locking files works in text-based approaches because it assumes few developers actually are working on the very same lines in a file and text merging is usually very straightforward.  We haven't in practice done much graphical merging yet and I'm not sure how well merging LabVIEW project files (though they are text) would go in practice....

[Elijah_K]

You can also merge VIs if you're using LabVIEW 8.5 or later.  The merge functionality is also available from the command line.

[TCPlomp]

This is A) the first time I hear an NI developer advising autopopulating folders.

B) very good advise to use LVLIBs. (allthough if you need to rename those the problem rises again)

Ton

[Elijah_K]

I do advocate the use of autopopulating folders.  We created them largely in response to feedback from users, but the reality is that you can save yourself a headache by keeping the hierarchy in your Project as close as possible to the hierarchy on disk (assuming it's logically organized).  I also think that is just saves me time.

One caveat to be aware of occurs when using Subversion (SVN).  Since LabVIEW will pull in the contents of the hidden '.svn' folder, which contains previous revisions, you should use Virtual Folders with SVN instead.  That being said, this is an issue we are actively looking at how to improve.