Issues with TFS and LabVIEW

[bigjoepops]

I am getting started with using TFS for source code control with LabVIEW.  I am using TFS 2013 and LabVIEW 2013.

 

I have a few questions:

 

What is the best way to move files from one project folder to another?  The "move on disk" doesn't appear to be a good option.  I want to be able to make file moves if needed and don't want my project to end up blowing up with conflicts.

 

It appears that once source control is set up in LabVIEW that all check in/check out operations need to happen in LabVIEW and not TFS or windows explorer.  Correct?

 

I just noticed the "Include callers when checking out files" option.  I am assuming that is probably a good option to select so that they callers will be modified and saved as needed.

 

Does having files set up as auto populating have any negative effects on how source control is done?

 

 

Unfortunately it appears that we are stuck using TFS for source control since the firmware developers are using it and it is a company application now.

 

Any help or guidance you can provide would be appreciated.

 

Thanks.

 

Joe

 

 

 

[ned]

I haven't used TFS and LabVIEW together, but I have used TFS, and I've used Perforce with LabVIEW, so I'm pretty sure these comments are correct.

 

I've never found a satisfactory way to move files. My recommendation is don't do it in LabVIEW. Close the project in LabVIEW, use TFS to move the files, then re-open the project and find the "missing" files. Unfortunately as far as I know there is no way to move a file both in source control and within the LabVIEW project simultaneously, although I would love to hear otherwise.

 

You can do your check-out/check-in operations either in LabVIEW or in TFS. If the status doesn't match, LabVIEW has a menu command to refresh source control status. I often find it convenient to check in individual files within the LabVIEW environment (for a small bug-fix), but if I'm making related changes to multiple files then after I'm done working, I close the entire project within LabVIEW (to confirm everything is saved) and then submit all the modified files at once within Perforce (or TFS in your case).

 

I leave "Include callers when checking out files" unchecked. It's whatever you prefer. I personally prefer to separate automatic changes (such as when a callee changes) from changes I made explicitly, and it doesn't bother me that much that I get a bunch of unsaved VIs when I close a project. I just don't save the automatic changes until I'm ready. You may prefer to do it the other way.

 

I haven't seen any interference between auto-populating folders and source control.

[Neil Pate]

Close the project in LabVIEW, use TFS to move the files, then re-open the project and find the "missing" files. 

 

This is what I used to do (using SVN) as I was scared that moving files using the LV project would break my VCS. Actually it turned out to be a far bigger pain constantly re-finding VIs in the LV Project.

 

Now I perform all file operations using the Project window and I just rely on the VCS tool (I use Hg now) to figure out what has gone wrong. Sure you may lose some of the file "history", but at least most of the time the LV Project does not get confused.

[ned]

I've also combined the two approaches - it's cumbersome but gets everything right. Move the files in the LabVIEW project. Close the project and save everything. Manually, on disk, move the files back to their original locations, then use the source control system to do the move.

 

Maybe Mercurial is smarter than Perforce about file moves, or I missed something in Perforce, because I haven't found a way to have it do the right thing with moved files.

[bigjoepops]

I've also combined the two approaches - it's cumbersome but gets everything right. Move the files in the LabVIEW project. Close the project and save everything. Manually, on disk, move the files back to their original locations, then use the source control system to do the move.

 

Maybe Mercurial is smarter than Perforce about file moves, or I missed something in Perforce, because I haven't found a way to have it do the right thing with moved files.

Ned,

 

Thanks for the reply.  I'm not sure I understand how your approach would work. When I tried to move things in LabVIEW I had to check them out of source control first.  If I tried this approach I would be stopped by source control when I attempted the move in LabVIEW.

 

It sounds like you might want to create a temporary project folder.  Open the project in LabVIEW and perform the moves and then save the project.  Check out the .lvproj file and replace it with the one that you had from the temporary project.  Perform the moves in source control and then check out the project and see what happens.

 

Unfortunately I can see a disaster happening with this.  It's like trying to disarm a nuclear bomb in a carwash at night with sunglasses.  I hate when the conflicts come up.  There can be a lot of them if you have an issue with a VI that is used in a lot of places in the project.

 

It just appears now that whatever folder structure you have created is very fixed and all you can really do is add/delete/change files and folders.  They discuss the importance of source control at NI Week, but it seems the tools are stuck at Windows 98 level.

[ak_nz]

This is what I used to do (using SVN) as I was scared that moving files using the LV project would break my VCS. Actually it turned out to be a far bigger pain constantly re-finding VIs in the LV Project.

 

Now I perform all file operations using the Project window and I just rely on the VCS tool (I use Hg now) to figure out what has gone wrong. Sure you may lose some of the file "history", but at least most of the time the LV Project does not get confused.

 

For SVN - using the TSVN Toolkit (from Viewpoint USA - see VIPM) helps alleviate this issue (as well as file renames). It makes the changes both in Project Explorer and SVN using the "Rename" command. THis basically performs the SVN rename (even if you just moved the file) and performs all the caller linking as well, just like normal rename / move on disk functions. The main downside is that you have to perform it one file at a time rather than bulk as you can with move on disk. We moved to SVN (away from both TFS and Perforce) because of this toolkit  - and this is one of the key reasons.

 

There is no such convenience for Perforce or TFS. Without the TSVN Toolkit this would be the same similar issue with SVN as well.

 

As far as source control goes - I still think that storing relative paths in all project and library-type xml files is the best best (where projects are still absolute paths). At least then a convention of "folder -> project file -> sub folders with all the project content" would make re-linking easier if you wanting to move things around outside of LabVIEW.

[ned]

This might be a difference with TFS. Perforce won't complain when you attempt to move files on disk that are in source control, so the method I explained works. If the source control system won't let you move a file on disk that isn't checked out then I don't have a good solution.

[bigjoepops]

For SVN - using the TSVN Toolkit (from Viewpoint USA - see VIPM) helps alleviate this issue (as well as file renames). It makes the changes both in Project Explorer and SVN using the "Rename" command. THis basically performs the SVN rename (even if you just moved the file) and performs all the caller linking as well, just like normal rename / move on disk functions. The main downside is that you have to perform it one file at a time rather than bulk as you can with move on disk. We moved to SVN (away from both TFS and Perforce) because of this toolkit  - and this is one of the key reasons.

 

There is no such convenience for Perforce or TFS. Without the TSVN Toolkit this would be the same similar issue with SVN as well.

 

As far as source control goes - I still think that storing relative paths in all project and library-type xml files is the best best (where projects are still absolute paths). At least then a convention of "folder -> project file -> sub folders with all the project content" would make re-linking easier if you wanting to move things around outside of LabVIEW.

ak_nz,

 

Do you know if there would be any issues with having TFS and SVN on the same system while I am trying to evaluate SVN?

 

Joe

[ak_nz]

ak_nz,

 

Do you know if there would be any issues with having TFS and SVN on the same system while I am trying to evaluate SVN?

 

Joe

 

As long as they are different working copies there should be no conflicts at all. I personally have both those, Perforce (legacy systems) and Git source control providers installed.

[bigjoepops]

Thanks for your input.  I loaded SVN, but haven't had a chance to evaluate it.  I'm reluctant to do that since TFS is a company application and I'm not sure my sole opinion will allow for a another program to be used.  There is supposed to be a session on source control at NI Week this year so I'm going to try to bring up my issues there and see what response I get.

[ThomasGutzler]

With TortoiseSVN you can always manually "fix" files that have been renamed by using the "Repair move" option.

For this to work you need a file that is missing and a file that hasn't been added. You select both, click Repair move and you get your version tracking back

Edited September 9, 2014 by ThomasGutzler

[ak_nz]

With TortoiseSVN you can always manually "fix" files that have been renamed by using the "Repair move" option.

For this to work you need a file that is missing and a file that hasn't been added. You select both, click Repair move and you get your version tracking back

snip.png

 

That's very useful to know, thanks!