Tortoise SVN & the LabVIEW project

[Lauren_CPC]

I am new to using Tortoise SVN.  We have a medium-sized application with 2 developers actively working on the same project.  I am curious about how people manage this setup.  For example, what is your procedure for updating and committing files when multiple people are simultaneously editing a project (or more specifically, separate VI's within a project)?

We had an issue where we were both working on different VI’s within a project.  We both had the project open, though were not actively changing the project.  Once we had both committed changes and merged everything (i.e. the project & aliases files had to be updated & conflicts resolved when the second person commits their work), we had a corrupt project file (would not open, pop-up box saying it was corrupt).  We were able to recover from this by going back to a previous version of the project, but this seems like such a basic issue that there has to be a better way to handle it.

It seems to me that the project and related files (.aliases, .iak, .lvlps) show that they have changed just by opening the project.  Do you need to avoid opening the project to work in parallel?  If so, how do you avoid cross-linking?  If you need to merge some of the .lvproj, .aliases type files is there a good way to do this?

I found this article, but would appreciate it if someone could elaborate:

http://www.ni.com/white-paper/4114/en

“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.”

[SteveChandler]

I don't think the .aliases or .lvps files can corrupt the project. Whenever a file is added to or removed or renamed that is part of a project then the project is modified. There is not really any way around that.

But here is what I do. I put every VI into an .lvlib. There are no files except the top level VI in my project that are not part of some library. If you have functionality grouped logically among several libraries then this really helps. The reason is that if you add or remove somethning in a library, the library is modified but not the project file. Once you have your project broken down into several libraries then you probably don't have to modify the project again.

You will have the same problem you did with the project file with your libraries. If you both are modifying the contents of the library then you will get this type of conflict. At least it is not with the project file anymore.

The best thing is to figure out what libraries you need and what VIs and controls make up that library. Create those libraries up front and add the VIs even if they are empty. If you edit a VI that is part of a library, it will not modify the library.

[Paul_F]

We usually ignore the project and allias file, each programmer has its oen proj, except a duplicate for builds.  All vis and other shared resources are in Tortoise.  This has worked for many projects with as many as 5 different engineers at the same time.  There is a learning curve with SVN. 

[smercurio_fc]

The .aliases file can be safely ignored. It stores the IP address of the computer that opened the project. That's why it seems to change every time you open the project file.

As for the .lvproj file, this is not something that should be ignored, as it contains the entire definition of the project.

[jaredforshey]

In my experience, I wouldn't expect this to result in project corruption.  Unless you've had this happen repeatedly, you might be able to just keep doing it the same way and have better luck.

It's not particularly elegent, but I usually simply stop committing my working copy of the project file once everything is set up.  Make sure everyone on your team leaves a good commit note when they do need to commit it, and resolve the conflict using the repository version every time you update.

[Mark_Yedinak]

We ignore all the .alias and .lvps files. We also set all of our VIs to separate the compiled code. This eliminates a lot of thrashing in SVN. We do not ignore project files. As Steve suggested, use libraies for core code. Also, the project file itself should not be changing that often once it is created. When we do run into a conflict we check with the developers involved and select one that should resolve the conflicts and manually update it if something gets lost when we resolve the conflict.