Leaderboard

When you're working in the same branch as your fellow developers, VIs and .lvclass files should be locked when you check them out. Ideally, you should get a warning when you try to check out a file that says "this file is already checked out. Any changes you make may not be able to check in. Are you sure you want to check the file out?" When you're working on different branches, I don't have any answers for you other than coordinate with your fellow developers. It's a largely unsolvable problem. Multiple branches can quickly break down in pure text languages too. True, changes can *often* be integrated together, but often they can't. LabVIEW has every function as a separate file, which is nice -- its surprisingly rare for multiple developers to need the same function simultaneously. The private data control of LV classes are a nasty bottleneck. As rare as it is to need to change the same function, two developers needing to add data to a class is more common. I don't really have a solution for this. The closest you can come is to check out the class, add a placeholder typedef and quickly check the class back in. Then in your own code, update the typedef to the data you actually need. This assumes you're not flattening the class to disk and trying to store data of this class type.

Hi we use the same branch - modify - merge pattern, we only have six developers here and the only advice I can give really is communication between the developers. That said some guide that help us (and only help they do not solve the problem) are : we do have a simple web tool so at a button click anybody can see what files other people have out on branches (very useful) Plus we try and keep the work / architecture spilt but it never really works. merge often / merge often. This is key and also relates to branches on text code. Keep branches as simple as possible and merge as often as possible. I strongly agree with this if one of use is doing a change that will result in lots of recompiles we plan that change in with everyone else. This is the one MAJOR problem I have with LabVIEW and to me it is a major problem. It is bad enought with six developers I cannot even imagine what it would be like with 50 + developers and yet this pattern works fine with 100+ developers with text languages...ah well not point in wishing it will go away. Dannyt

Selling and especially supporting XP embedded on hardware for development is not easy. In fact I think it is almost impossible or you would need a well paid support program from the hardware supplier. XP embedded is not a plug in the CD-ROM, launch setup.exe and voila thing. It is in fact very far from that. If you look for such an experience you are much better of with a standard XP installation. Using XP embedded means knowing and understanding in detail how you configure a build (yes you configure the components you want to have deployed to your hardware). So it is not like purchasing hardware with a preinstalled XP embedded. XP embedded will be always installed by you, the final assembler of the system) according to the configuration you made in the XP embedded Tools. And what components you will want to install will partly depend on the hardware (where NI would probably get in with a detailed list of what modules are required) but also on your intended use of the system. So NI can not really make that installation for you as they would have to decide between installing anything, basically creating a somewhat leaner XP install, or install whatever they find necessary which would likely leave you with some lack of support for some functions. Also in XP embedded your final application is usually also part of the image that you deploy to the system. Rolf Kalbermatter