Which files to include or ignore in Subversion

[Fitz]

We are trying to imlpement TortoiseSVN/Subversion within a LabVIEW 8.6 development team. Meta-diff and lvmerge are working properly thanks to the posts in this thread.

However, we are having trouble preventing corruption of the labVIEW project files during development. We had initially tried committing and working from an import that did not include any alias files.

My question is: which files should be placed under version control to ensure proper functioning of the project and, if applicable, which files should be ignored?

Unfortunately, I'm not familiar with labVIEW development, but am just helping the team with source control. Please give any advice about how to best use Subversion with labVIEW.

Again, the diff/merge tools are working already through TortoiseSVN, I'm just having a hard time knowing which types of files in a labVIEW project (8.6) should be under version control to best prevent corruption/conflits.

Thanks in advance for the help.

[MattWhitlock]

I've used TortoiseSVN with LabVIEW for quite some time without issues with corruption.  But my use case may be somewhat different from yours.

• I only exclude *.aliases
• I include everything else in the project folder
• I only use TortoiseSVN's facilities for updates, commits, etc. through right-click menus with Windows Explorer
• I do not use any SCC integration with LabVIEW, Visual Studio, etc.
• I do updates and commits frequently
• I do all TortoiseSVN commands at the project directory level. i.e. if I have a .lvproj in ...\Project1 with everything contained in folders under Project1, I do all updates, commits, etc. on the Project1 folder itself.

I do everything through Windows Explorer as I generally work on mixed projects with various engineering tools in nested folders. That is, I use LabVIEW, Visual Studio for C# ASP.NET and SQL Server work, Visio, or whatever else to get the work done.  I find that it's easiest to do all version control in one place rather than use the SCC hooks in each individual program.

Matt

[tst]

There are only two are three files which are explicitly designed to be ignored by SCC and those are the ones sitting by the project. Those are the aliases file, the lvlps file (if I remember correctly) and I think there's another one. The LabVIEW help should have an explicit reference to those.

These files, however, are basic ASCII files and should not cause corruptions. If you do get corruptions, you are probably merging the project file or possibly .lvclass files. I don't have any practical experience with doing this, but my understanding is that this is something which you generally don't want to do, because even though these are also ASCII XML files, they include some binary data which may get destroyed by the merge.

You might think that this poses a problem if you have mupltiple developers working on the same project, but in general, I would say that not every file needs to be explicitly placed in the project. Having the files in the project helps you access them and helps if you have conflicts, but is not strictly necessary most of the time. As such, you may find it prudent to tell your developers to not save their project files unless they make an explicit change to the project (like adding targets or a build). You should then get the other developers to update the project file as soon as possible (either manually or by using hooks on the repository or some of the alerting tools that the guys who release TSVN also release).

[MattWhitlock]

Good points, I also tend to exclude the .lvlps file.  The reason I exclude it and the .aliases is that these files may be modified even if you don't make any changes to the project, and often results in conflicts when doing update/commit.  For example, the .aliases file stores the IP address of the computer, and each developer will be in conflict. Basically just saves on hassle.

I tend to be very distrustful of the Merge process with LabVIEW files and prefer to work with the other developer directly to determine what has changed.  I'm fine with conflicts cropping up from time to time as it forces communication between developers.

I think there are pros/cons with the project w/r/t including everything in the project or just the essentials. Auto-populating folders can cause issues for sure. I also prefer to include just the essentials in the project and keep it easy.