Jump to content

Recommended Posts

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

 

 

 

Link to comment

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.

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment

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.

Link to comment
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

Link to comment
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.

Link to comment
  • 3 weeks later...

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.

Link to comment
  • 1 month later...

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 :)

attachicon.gifsnip.png

 

That's very useful to know, thanks!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.