LabVIEW and Perforce documentation out of date?

[Perreijn]

Hi Guys,

The LabVIEW project I have been working on for a number of years by now has always been a 'one man show'. I was the only one working on it and the project sat on my hard drive of my only workstation. Now I have a challenge: I am getting a new colleague and we should both be able to work on it simulataneously.
It's pretty clear I need a source code control (SCC) system and according to NI's documentation (http://www.ni.com/white-paper/4114/en/) Perforce is still the recommended system.
The documentation is lacking however and I'm not talking about Perforce's own documentation (which is pretty good). The 'official' documentation on how to use Perforce with LabVIEW is IMHO too old and limited: https://decibel.ni.com/content/docs/DOC-3203
There are a number of issues with that page:

- It's a webpage from 2009, converted to PDF and among others the screenshots show an old, Windows XP version of P4V. The current version of P4V is very different.
- The section 'Licensing and Compatibility' is out of date: the current version has a limit of 20 users or 20 workspaces (not 2 users, 5 workspaces).
The Perforce server is now called Helix Versioning Engine (P4D).
- The first paragraph in section 'Installation and Repository considerations' can be removed, Perforce now does provide a standard uninstaller.

The biggest issue however is that I'm missing a more extensive howto on how exactly to setup a multi-user LabVIEW environment. There are more steps involved than are written in the PDF. One example: Perforce Versioning Engine by default allows everyone to create their own account and also has write permissions set to everyone. It's very important to quickly change this and raise the security level to at least 2 (password protection). Of course this is mentioned in the 200+ page manual, but it's easy to miss. Another gotcha: directories with '#' in the name (e.g. c#source) will cause problems.

By lots of trial and error I have managed to setup a depot on a separate Windows 2012 server, create users, set permissions, create a workspace on my laptop and link it to the depot. I have played around a bit with text files (check out, change, submit) and this works. I still have some questions before I upload my existing 5 GB+ LabVIEW project folder to the depot:

- What is the correct order for uploading an existing LabVIEW project to the depot for the first time? My guess would be: create a local workspace (e.g. c:\localcode), copy/move the LabVIEW project folder to c:\localcode, add and submit the files to the depot, open LabVIEW, configure source control, open the .lvproj file and see if it's SCC enabled.
- Are the LabVIEW source control settings specific to each LabVIEW-project or is it a central setting for all projects on my computer?
- My colleague has a new laptop with LabVIEW 8.6. How can I setup his computer to use the newly created depot without creating duplicates or conflicts?
- Any other tips on working with multiple computers/users on one LabVIEW project?

Sorry if this sounds like a rant, but I really want to give Perforce a fair chance and don't want to mess up my existing project.
Thank you very much for your time and effort.

Paul

[Intaris]

I used Perforce and didn't like it.

If they still use a "Check-out = Lock" scheme then avoid it.  That plays havoc with LabVIEW especially if you are doing testing, imagine having the entire repository of a product locked because you're testing it.... What if your PC crashes or your colleague gets sick, then you need to go to the Perforce server and manually free up those files.

IMHO Perforce should be avoided.  There are toolkits to interface with SVN or GIT out there, I would recommend one of these.

[nathand]

I've used Perforce and LabVIEW together happily at several companies, although it's been a few years and I'm not currently using it so I can't verify specific instructions. There are several ways to configure and use Perforce. I personally don't set it up the way it's described in that PDF that you mentioned. I prefer to keep all my LabVIEW code in one depot, with different folders for different projects, and to use the Perforce Command-Line client rather than the Perforce SCM client (it just worked better that way - I don't remember why, and maybe it's been fixed). Unlike Intaris, I like the option that locks binary files on check-out because it avoids conflicts that are difficult to merge, but you can change that setting at any time (and even on a per-file basis) if you find it interferes with your workflow.

---

Perreijn wrote:

- What is the correct order for uploading an existing LabVIEW project to the depot for the first time? My guess would be: create a local workspace (e.g. c:\localcode), copy/move the LabVIEW project folder to c:\localcode, add and submit the files to the depot, open LabVIEW, configure source control, open the .lvproj file and see if it's SCC enabled.

---

You can do it that way, or you can create a new workspace pointing at the directory where your source code already resides, and avoid copying it over.

---

@Perreijn wrote:

- Are the LabVIEW source control settings specific to each LabVIEW-project or is it a central setting for all projects on my computer?

---

Source control settings are saved in the LabVIEW.ini file, so they apply to all projects. I always use the Perforce command-line client; I never understood the LabVIEW option to associate the source control settings with a specific project. A quick search pulled up this page http://digital.ni.com/public.nsf/allkb/881CA9D71A6A5E7F8625716B0058B712 though which indicates that the project just tells LabVIEW which directory to use, and doesn't need to be an actual LabVIEW project.

---

@Perreijn wrote:

- My colleague has a new laptop with LabVIEW 8.6. How can I setup his computer to use the newly created depot without creating duplicates or conflicts?

---

You should create separate workspaces for you and your colleague. You probably want them configured to use the same directory names, although that's not a requirement (however, since LabVIEW tends to look for things at the same path, you're less likely to get problems if everyone stores their LabVIEW code in identically-named folders across different computers). If you're working on multiple computers, you may want one workspace per computer. A workspace maps folders from the depot to folders on the local computer, and when files are checked out, they're checked out in a particular workspace.

---

@Perreijn wrote:

- Any other tips on working with multiple computers/users on one LabVIEW project?

---

I would avoid checking in any files that LabVIEW automatically (re)creates, in particular the aliases and lvlps files that LabVIEW creates for each lvproj file. You can set Perforce to ignore files with those extensions, if I remember correctly.

Keep your compiled code in a separate folder from your source. You may find it convenient to check in your compiled application, if you want to get a to a particular compiled version quickly.

LabVIEW often makes small, automatic changes to files, which cause source control to report that the file has changed even though the code hasn't been modified. You can either check in those changes or ignore them until you make an actual change (I usually ignore them). Newer versions of LabVIEW have an option to separate compiled code, which should help with this problem; I've seen occasional error reports due to this feature, and I haven't tried it.

[Hooovahh]

---

@Intaris wrote:

If they still use a "Check-out = Lock" scheme then avoid it.  That plays havoc with LabVIEW especially if you are doing testing, imagine having the entire repository of a product locked because you're testing it..

---

Why would you need to lock the whole repository to check the code?

I've used SVN for years with the needs-lock, and now I'm using Perforce and the two share such similar concepts and schemes that I'm not sure how you could recommend one without the other.

I tried the integration with LabVIEW SCC that is built in and I hated it.  It was nice being able to add SCC to LabVIEW without needing to download some addon or toolkit, but it didn't feel as polished.  Probably because NI made it so long ago and I don't think it's been updated since.  

Maybe it was because I used SVN first but I got so used to just opening the code save, see that I don't have the lock (which brings up the explorer window) where I then right click and get the lock, then go back to editing my code.  To help with that work flow I've started using P4Exp which is an explorer plugin for Perforce.  It isn't as good as tortoise SVN but then again SVN only had the explorer interface so it had to be good.  Once you get used to the concepts and using P4V you might want to try out the explorer plugin.

[Intaris]

I was using the built-in project integration and my overall emotion was one of anger and frustration.

I don't remember the exact causes but I was left frequently with the situation where having edited code on one machine (I was doing parallel PC and MAC development) frequently required me to bounce between machines in order to be able to use the thing properly (unlock, checkout, bounce, unlock etc.).  I had no idea at the time how to change this behaviour.  It may no longer be the default.  One problem was the locks which were far too frequent (it felt like a simply checkout was locking the files but I may be wrong) the other was the measly number of parallel users allowed which (if a PC crashed while logged in) led to me on occasion having no "free" accounts to even log into the server with.  That's a doozy.  Try fixing that when you can't log in in the first place.

Many (if not all) of these issues may have been my own fault, but as I say in my first sentence, the overall memory is one of anger and frustration.  Things may have changed since then.

[Intaris]

BTW, it seems like my problems were all due to the LabVIEW IDE.

http://zone.ni.com/reference/en-XX/help/371361J-01/lvdialog/perf_cfg_opt_db/

Lists the default as being "Lock files when checking out".....

[SnowMule]

Before you implement anything like this, make sure you've got a good backup.

We use Perforce here... I rather like the locking (outside of the "file is read-only, do wat?") because there's no good diff/merge tool in LabVIEW. 

P4's support is pretty good, they can help you through a lot of these issues.  Lots of phone calls to them when we were getting everything running.

[Perreijn]

Thank you all for your thoughts, tips and recommendations.
I took the plunge and added my project and all of its files to Perforce. For future reference: here are my experiences.

• After having finally uploaded the 8000+ files in my project folder to the depot, I wanted to check if everything was there. At first I was worried, because the number of files in the depot was lower than in my laptop's folder. So, I used WinMerge to check and luckily it's not an error or bug. Apparently Perforce doesn't upload .suo and .svn files as well as empty folders.
  The .suo and .svn files were part of folder with C# and C++ code and they are used for other source control systems. I can imagine that these files might conflict with Perforce own settings, so it's probably for the best that it's not part of the depot.
• Checking files out and in works as it should and all within LabVIEW's project explorer. The project explorer doesn't always show that a file is checked out on another computer, but luckily it warns you if you attempt to check out a file that's already checked out by another user.
• What to do with LabVIEW's project file is still a bit confusing. As recommended by the white paper (http://www.ni.com/white-paper/4114/en/) the project file is also part of the depot. However, the second paragraph of section 'Managing the Project File in Source Code Control' isn't very realistic: renaming files doesn't happen very often, but adding new files to a project happens all the time. In practice this would mean that my colleague and I both would get a prompt to checkout, save and submit the project file all the time. In theory we could merge the changes (since the project file is similar to a XML file), but my gut feeling says it's wiser to have just one developer (me) manage and save the file. The other developer would ignore prompts to save the project file and have to consult me for any changes. Not ideal, but I can live with it.

All in all, I'm happy with Perforce's performance and the integration with LabVIEW. Let's hope it stays that way 

[Hooovahh]

---

@Intaris wrote:

BTW, it seems like my problems were all due to the LabVIEW IDE.

http://zone.ni.com/reference/en-XX/help/371361J-01/lvdialog/perf_cfg_opt_db/

Lists the default as being "Lock files when checking out".....

---

I think this goes into your preffered work flow.  There is basically two major ways of thinking, lock and commit, or merge.  I prefer lock and commit for LabVIEW since the merge isn't always perfect due to the binary nature of LabVIEW.

So I prefer to lock a VI when editing it, making it not read-only, allowing me to edit my code.  Code is generally broken up into sub components (modules/actors or whatever), so a developer generally locks all VIs in that modules, edits them, and commits them.  Shared components are in a shared folder where developers just lock the one or two VIs they need at a time.

The one feature I tried of the IDE that I didn't like was the "Lock a VI if read-only".  I compulsivly save so often that I don't really have a problem making edits to a VI that I don't have permissions.  I'll change a couple things, save, then see I don't have the lock and try to get it.

@Perreijn

Glad to hear it is working out so far.  I personally do commit the project, but only lock it when I intend on making changes.  I think we also configured perforce to not treat the project as text but as binary, which again follows the lock commit, instead of merge.

[aSquared]

Hi,

(LabVIEW 2013 SP1 and Teststand 2014)

I have been using SVN and now want to use Perforce.

I am having the same difficulties with the documentation...

I have installed perforce, connected to the server successfully, configured the client spec, but I dont feel the getting-started documentation is enough...

Where can I find the best documentation to -

1. Configure P4V in Windows as my default SCC provider. (should I realy manually edit the registry ?)

2. Configure the Client Spec files. (found documentation and successfully did it using the command line)

3. Configure LabVIEW to check out files when developing.

4. Configure Teststand to check out files when developing.

5. Configure LabVIEW executable (The Teststand UI) to have access to the files in test mode.

Do you know anything about using issues when using Perforce 64-bit with LabVIEW or Teststand 32-bit ?

Amitai.