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

 

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.


  • Similar Content

    • By etgohomeok
      I use SVN for version control in my project and am often faced with many conflicted VIs that must be dealt with. I have found that frequently, the changes causing these conflicts are not "real" changes (for example, a wire was moved or a typedef for a cluster control was changed). So, I am trying to create a tool that queries my project directory for any VIs that have conflicts, and running the VI Comparison tool with only non-cosmetic changes enabled to automatically find VIs that don't have any "real" changes and marked the conflicts as resolved. I would like to build the tool into a .exe because I would like to be able to run this tool from the command-line so that I can create a right-click menu item in my Windows environment to easily run the tool from any folder containing conflicted files.
       
      I found vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi which performs the comparison operation, allows me to specify which types of changes to detect, and returns if there are differences. This is exactly what I need and it works perfectly in the development environment. However, when I build my tool to a .exe file, I get a LabVIEW error with the following description:
      Error 1574 occurred at Open VI Reference in SCCSup Compare Two VIs.vi->Resolve False Conflicts.vi Possible reason(s): LabVIEW:  (Hex 0x626) Cannot open a file with separated compiled code in the LabVIEW Run-Time Engine. An error occurred loading VI 'my.vi'. LabVIEW load error code 59: The source file's compiled code has been separated, and this version of LabVIEW does not have access to separated Where my.vi is the path to the VI that it is attempting to compare. All of the VIs in my project have "Separate compiled code" enabled since I use version control on them, therefore turning it off it not an option. Is there any way to get around this issue?
    • By PaulL
      Here is the set-up:
       
      I have a component project library (StepperMotor.lvlib) that I have moved to the userlib in order to facilitate reuse over multiple projects.  Within the library I have
      1) a strict typedef (StepperMotor.ctl) cluster that contains a numeric control for expressing the maximum output step rate.
      2) the StepperMotor.lvclass, an abstract class that contains effectively virtual methods (they do nothing but wire inputs to outputs) and LabVIEW-generated accessor methods for the two items in the class private data.
      This is LabVIEW 2013 SP1 on Windows 8.1.
       
       
      OK, so I start with everything clean (git status reports clean, LabVIEW opens and closes the library without prompting for changes).
      1) Then I open the StepperMotor.ctl directly from Windows Explorer (hence not opening the library), change the range of the numeric from 2 kHz to 4 kHz, and save it.
       
       
      2) Then I open the library, make no further changes, and attempt to close the library.  LabVIEW correctly prompts me to save changes.  I opt to close the project without saving changes, however.
       
      3) Next I discard the change to StepperMotor.ctl using git.  (I have been using Discard in SourceTree, or a git reset --hard command.)  Then git status returns a clean status.
       
      4) I open the project and attempt to close it.  Since I have reverted all changes, LabVIEW does not prompt to save changes.
       
      So far, so good.  This is expected behavior.
       
      Now, I repeat the steps, except that in step
      1) I open the library first, open the typedef control from the project, make the same change, save the control (without applying the changes), and close the project (without saving).
      2) is the same as above (OK).
      3) is the same as above.  Again, git status shows me everything is clean.
      4) I perform the same action as above, but this time LabVIEW prompts me to save all the accessor methods on the class, citing a changed typedef (even though if I open the typedef the range is indeed back to its original value).  This is unexpected behavior.
       
      Worse yet, even if I perform a git reset --hard and verify with a git status that everything is clean, if I open and immediately attempt to close the project, LabVIEW still prompts to save, citing "Type Definition modified".  This is indeed problematic.
       
      (Further note: If I let LabVIEW save the changes, git status still shows clean, and LabVIEW opens and closes the project without prompts.)
       
       
       
       



    • By PaulL
      Has anyone actually configured Git to work with LVCompare or LVMerge?  (I've seen some threads on various boards saying it "should be something like" <x>, but it isn't quite <x> and I haven't found anywhere that someone has actually described it successfully.)
       
      Notes:
      I know how to configure TortoiseSVN to work with LVCompare and LVMerge.  My new employer is moving to Git (some good, some bad in that, in my opinion, but that is another topic).
       
      I have been using Git for a few months now with reasonable success and decided I should try to set up graphical differencing.  [OK, in practice I've rarely used graphical differencing for any practical purpose, and graphical merging probably never for any actual code.]  Anyway, I think I've learned some things trying to figure out how to get this to work--but I don't have it working yet.
       
      I use the Atlassian SourceTree client at present (and sometimes the shell).  For the purposes of this discussion it might be more helpful to share the relevant text in the .gitconfig file (and any associated scripts, if necessary).
      As others have mentioned, Git itself (SourceTree similarly) does not distinguish which diff tool to call according to the file extension.  This seems like it could be a significant drawback.
       
      What I have tried:
      I added this (and variants of it) to my .gitconfig file:
       
      [difftool "LVCompare"] path = C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe keepBackup = false trustExitCode = false[difftool "LVCompare"] cmd = "C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe" "$LOCAL" "$REMOTE"[diff] tool = LVCompare SourceTree reports errors on start-up, so don't use this!  Lol!
       
      Maybe I need to add a script, too.  I'm not sure that I'm really all that close, honestly.
       
      [bigger question: Why is this difficult in the first place?]
    • By ShaunR
      Very pleased to see the New JSON Encode and Decode in the palettes of LabVIEW 2013. I've looked at using them instead of the various libraries out there and I'm in two minds whether I will convert my current apps or use them in the future instead of those 3rd party libraries now I have had a chance to play..
       
      Let's start off by saying they work great  They are orders of magnitude faster than 3rd party ones and they adhere vehemently to the JSON standard. It's the last bit I'm in two minds about.
       
      JSON is subset of Javascript (EMACS). Javascript is dynamically typed, which means that any variable can hold any type and although a string may have quotes around it, it does not preclude inserting it into, or operating on as a numeric type. Whilst the JSON spec does specify that string types be encased in quotes, Javascript (and PHP, for that matter) programmers don't really care and it doesn't break their code if they are present or not. Therefore it is very common to see quotes around numerics and even quotes left off of strings and most parsers will cope with this.
       
      LabVIEW is strictly typed and when the JSON Decode encounters quotes, it will error if you have defined the field as, say, a double. and then will not process any further fields. This is a right, royal pain! It also misses a trick that would make our lives so much easier and our code much simpler.
       
      Take, for example, the following real JSON stream from MTGox.
       
       
      {    "channel":"dbf1dee9-4f2e-4a08-8cb7-748919a71b21",    "channel_name":"trade.BTC",    "op":"private",    "origin":"broadcast",    "private":"trade",    "trade":{                   "type":"trade",                   "date":1376196221,                   "amount":0.3333,                   "price":102.95507,                   "tid":"1376196221462784"                  ,"amount_int":"33330000",                   "price_int":"10295507",                   "item":"BTC",                   "price_currency":"USD",                   "trade_type":"ask",                   "primary":"Y",                   "properties":"limit"                }}  
      The "price_int"," amount_int" are encased in quotes when quite clearly they are integers and, more importantly, we need to manipulate them as integers. This forces the use of cluster elements that are strings and then to convert those fields to the appropriate type. It is compounded further since the structure is nested which means we have to unbundle all of the elements and then re-bundle to our desired types as we cannot use a single cluster definition. Additionally, the "date" is a numeric of the correct type, but that is not very useful in this scenario since it will need to be converted to a string. So defining that field in the decoding cluster as a string would have been a bonus. .
       
       
      This is the conversion using the native JSON decode.vi.
       

       
       
      This is using the JSON API available in the CR.
       

       
      The JSON API in the CR is much more forgiving in that the cluster, alone, decides on the type. So type conversion can be done transparently by defining the cluster regardless if a value is quoted or not. This yields a much simple, easier to maintain VI and, should the server generating the JSON decide to strictly adhere to removing quotes from integers; it will not break our code as it would with the native VIs.
       
      The native JSON decode has a "strict validation" boolean that states
       
       
       
      It would be useful if this boolean also disabled type checking of quoted strings. It would also be useful if it didn't stop at the first field it couldn't interpret and tried harder to continue. I could live without the latter, but not sure I can without the former - hence my ambivalence.
       
      Did I mention how fast the native VIs are? 
×
×
  • Create New...

Important Information

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