Perforce Workspace

[pete_dunham]

I am starting up LabVIEW development at a client's site that uses Perforce SCC.

I have been debating on how to setup the workspace for a development machine and finally decided on having my workspace be the entire C:\.

This seemed to be the only solution to include <instr> and <vi> directory dependencies in the SCC.

I am struggling to understand how to include all my dependencies without moving files in and out of a smaller-scope workspace.

My gut feeling is that having my C:\ as a workspace will come back to bite me. Has anyone else done this?

I have used SVN in the past, so my hesitation comes from my SVN experience and now using a new SCC (Perforce).

Thanks!

Pete

[crelf]

I'm not a Perforce guy, but setting your whole drive as your workspace sounds like a mistake to me. Why do you want to include <instr> and <vi.lib> as dependancies? Sounds like you need to take a look a VI Package Manager.

[jgcode]

I am starting up LabVIEW development at a client's site that uses Perforce SCC.

I have been debating on how to setup the workspace for a development machine and finally decided on having my workspace be the entire C:\.

This seemed to be the only solution to include <instr> and <vi> directory dependencies in the SCC.

I am struggling to understand how to include all my dependencies without moving files in and out of a smaller-scope workspace.

My gut feeling is that having my C:\ as a workspace will come back to bite me. Has anyone else done this?

I have used SVN in the past, so my hesitation comes from my SVN experience and now using a new SCC (Perforce).

I use Perforce, my local files sits under D:\Jobs or something similar.

Having the whole C:\ drive under SCC makes no sense to me either.

At the end of the day you only want your source code in SCC and maybe project files (word docs etc....)

As Crelf recommended I would review your reuse strategy, whilst others like to check in/out directly into vi.lib etc... (so there must be some logic to it?) I prefer VIPM, and it would be a good place to start for you.

That way your dist code is under vi.lib (etc...) but your src can sit where-ever.

-JG

[Swinders]

We have used Perforce for a few years and have our workspace as the whole D drive. Our PC's have their hard drives partitioned as a C drive for windows and applications and D drive for the user data. LabVIEW is installed in D:\Program Files and our user areas in D:\Documents and Settings\User\My Documents\LabVIEW. The decision to use the entire D drive was based on the need to include the user.lib and instr.lib (we have written our own custom instrument drivers) folders in the Perforce depot. This does not mean that the entire D drive is held under Perforce, what we do is set the View to target folders in the Perforce Depot to our workspaces. An example of our view settings would be:

//depot/... "//workspace/Documents and Settings/user/My Documents/LabVIEW/..." "-//depot/LV 2009/..." "//workspace/Documents and Settings/user/My Documents/LabVIEW/LV 2009/..." "//depot/LV 2009/..." "//workspace/Program Files/National Instruments/LabVIEW 2009/..." "-//depot/Requirements documents/..." "//workspace/Documents and Settings/user/My Documents/LabVIEW/Requirements documents/..." "//depot/Requirements documents/..." "//workspace/Documents and Settings/user/My Documents/Requirements Documents/..." 

This targets the entire depot to the LabVIEW folder in My Documents but removes the "LabVIEW 2009 folder" and targets this to the LabVIEW programs folder. We also have a "Requirements Documents" folder that is targeted to our My Documents Folder.

Our original thought was to hold the instr.lib and user.lib folders in a separate workspace but LabVIEW can not handle more than one workspace so it proved to be difficult to keep everything in sync.

Edited February 18, 2011 by Swinders

[pete_dunham]

Thanks for the replies.

I'm not a Perforce guy, but setting your whole drive as your workspace sounds like a mistake to me. Why do you want to include <instr> and <vi.lib> as dependancies? Sounds like you need to take a look a VI Package Manager.

I am going to look into VI Package Manager and see how it fits into my system; maybe this will help solve my Perforce dilemma.

This does not mean that the entire D drive is held under Perforce, what we do is set the View to target folders in the Perforce Depot to our workspaces.

Yes, maybe this wasn't clear in my first post. While I can view my C: drive in Perforce, the only folder that are held under SCC (by Perforce) are folders that I have chosen to be under control.

[jed]

Thanks for the replies.

I am going to look into VI Package Manager and see how it fits into my system; maybe this will help solve my Perforce dilemma.

Yes, maybe this wasn't clear in my first post. While I can view my C: drive in Perforce, the only folder that are held under SCC (by Perforce) are folders that I have chosen to be under control.

Sorry I'm late to the party.

I have been using P4 for > 10 years with Labview. I whole-heartedly agree that you don't want your workspace to be c:\

I typically work out of c:\Users\USER\p4 on my personal machine (windows 7) and map the specific client's code to c:\project on their machine.

I use VIPM extensively (I use the pro version so that I can include my own libraries, but you don't need to do that). I include a VIPC file with my distros so that I can easily get all those libraries. You could just archive your VIPM cache into P4 somewhere.

Unfortunately, since all those drivers are dumped into the non-controlled, non manageable instlib folder, it's VERY hard to maintain that with P4. I have two methods...

1) Don't manage the instrument code. Zip any dependent libs up and include them in a support/drivers section of your main code area along with a basic readme to explain where they need to go. This is what I usually do. Hopefully I do not have to make changes to their code. If I do, I treat it like it's a portion of my own code.

2) You can also include just the <user.lib> and <inst.lib> folders in your workspace definition. Just be careful when upgrading LV.

I hope this helped a little. I agree it's a pain in the neck to deal with it.