Leaderboard

No advice in the merge topic other than don't do it. LabVIEW files are obviously binary in nature, and merge doesn't work well. That being said some developers do implement a merge paradigm in LabVIEW and SVN. LabVIEW has some file compare tools to see what changes have changed from one revision to another but I have no idea how well they work in a SCC. SVN also can work in the Lock/Commit paradigm where VI files will be read-only until you have requested a lock from the server (look into needs-lock). At which point you can edit the file and commit changes but no one else can. If they attempt to get a lock SVN will say what user has the lock at which point you can ask them if they are still working on it. Dividing up the application into code modules and assigning a developer their set of code usually minimizes the number of times you need to ask a developer about their part of the code, but it happens. BTW I just suggest Tortoise SVN, which is the Windows Explorer extension. If the file is read-only, LabVIEW will complain when you go to save, at which point a save dialog will come up. From here you can right click the file and choose to get the lock, cancel the save dialog, and resave the VI (which shouldn't be read-only any more). Some other toolkits help in things like a rename. If you need to rename or move a file, then LabVIEW needs to be aware of the change (the project and files that link to it) and SVN needs to know it was renamed. Some of these 3rd party tools like ViewPoint can do this but it is generally a pain. As for file structure. Code that is reuse, and not part of the project needs to be found by a single common location. My advice is either the vi.lib or user.lib. You take your common code, package it up with VIPM, and then have all your project code link to that common stuff there. The source to the VIPM packages can be in a separate reuse SVN repository, but your code only ever links to the code from the installed location of user.lib. It can be more steps to make changes, since instead of changing the code in user.lib you should change the package source, build a new package, release it, then install it. Where previously you would be just used to editing the VIs as they are. Another alternative I've heard of but am less of a fan of, is to checkout the reuse repository to your user.lib. Then you can edit the reuse source and commit it back to SCC. This has advantages and disadvantages of course