Leaderboard

All software is "prototype" until at least 20 people have complained about it

Actually, it probably wouldn't be. Most people are not you. You play with it, learn from it and know enough to know what to do if there's a problem. Many LV developers aren't. Enough of them will ignore or not notice such a warning to create a support burden. You can see that AQ says this happens even when people have to actively work around the protection to get to the code, so you can be sure it will happen if it's simple to access. The main difference between LV and Minecraft, in that regard, is that Minecraft is a free/cheap game developed by a single person and LV is an expensive IDE used for creating working systems - people expect the latter to work a lot more than they do the former and so the support for it has to be at a higher level. And for what it's worth, I'm with you on this. I also like access to the private stuff, but I've seen enough of it to know that there's a good reason for *some* it to remain private.

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.