‎02-01-2019 08:52 AM
I'm working on several LabVIEW Projects of modest size (a few hundred VIs and TypeDefs), each contained in a LabVIEW Project (.lvprog), each maintained in its own Directory Tree (named for the Project, with physical Folders matching the Project's Virtual Folders), and each under its own SVN Repository. I typically start my work day by updating the Project, open it, often bring all of the VIs into memory (to inspect them, find where the sub-VI I'm modifying is called, etc.), and at the end of the day, I Commit, often updating 4-10 VIs (a relatively small number).
Then I go home, and do a "little more work", but on another computer. Both computers are running the same OS (Windows 10 x64, I think Version 1803 or 1809), and have the same LabVIEW installation (including Toolkits, Modules, Drivers, and settings). I again go through the Update, Work, Commit cycle.
What's peculiar is that the Update cycle typically involve 20 or so VI, many of which I never "touched" (other than perhaps opened to see where another VI was called). Now, I may have modified a VI that was used by the "changed" VI in question --- oh, I think I just figured it out, it's the "separate the Compiled Code", or something like that.
That's it! Type "Separate Compiled Code" into Google and it brings up a LabVIEW Help Message explaining the whole thing! Sometimes "slowing down" by writing Documentation, talking to an NI Support Engineer, or even posting a question on the LabVIEW Forum can make you suddenly "much smarter" -- I'm going to leave this message here, change the Title to make it possibly more helpful for other Forum members, and gain a few "Humility" points.
Bob Schor
Solved! Go to Solution.
‎02-01-2019 09:12 AM
Was simple to do (manage as Project Property). Just did this for my current Project, "marked" all VIs and Types, did a Commit, and essentially all the VIs and TypeDefs seemed to be committed. The Proof will come this evening when I do an Update, and see if I (only) get the VIs I actually changed. I'm "cautiously optimistic".
Bob Schor
‎02-01-2019 10:05 AM
Another good setting to change is to "Separate compiled code from new items" under Tools > Options > Environment.
‎02-01-2019 12:18 PM
@Jacobson-ni wrote:
Another good setting to change is to "Separate compiled code from new items" under Tools > Options > Environment.
I believe this makes it so all new projects have the "Separate compiled code" thingy checked.
One thing to make sure is to look at all your libraries under your project to make sure they've inherited the change.
‎02-04-2019 10:49 AM
Here is a nice video from Delacor which I think is a great primer to source code control. It shows the setup and workflow when using TortoiseSVN. Also, here is their blog post where they have similar videos for bringing up Git or Mercurial.
‎02-05-2019 08:06 AM
Thanks. In my One Man Shop, I prefer using Tortoise SVN without any "add-on" tools (except my own tools that, for example, allows me to create Executables whose Version Number uses the SVN Revision as the "Build" (1.0.0.345) part of the Version).
Bob Schor
‎02-05-2019 10:16 AM
@Bob_Schor wrote:
Thanks. In my One Man Shop, I prefer using Tortoise SVN without any "add-on" tools (except my own tools that, for example, allows me to create Executables whose Version Number uses the SVN Revision as the "Build" (1.0.0.345) part of the Version).
Bob Schor
I use TSVN at home and the revision is already in the thousands.