How to manage "3rd party" sub-projects in Perforce?

Our group integrates a bunch of different sub-blocks into our main project and we are trying to determine the best way to manage all of these different pieces of intellectual property. (From here on out I will refer to these sub-projects as pieces of IP "Intellectual Property").

The IP will be a mixture of third party vendor IP, previous projects IP and new to this project IP. Here are some of the ideas we are considering for managing all the different pieces of IP:

1. Publish releases on a physical drive and have th开发者_JS百科e main project point to the correct releases.

   PROS - Little to no dependencies on the SCM: seems simpler to manage initially:

   CONS - Must remember to keep each physical design center up to date:

2. Use Perforce client spec views to include the correct version.

   PROS - Able to quickly see what IPs are being used in the client spec:

   CONS - With a lot of IPs the client spec becomes very messy and hard to manage: each team member manages there own client spec (inconsistencies): the very thing determining which IP version to use is not under SCM (by default):

3. Integrate the the different releases into a single one line client view.

   PROS - Makes client spec maintenance dead simple: any change to the IP version is easly observable with the standard Perforce tools:

   CONS - Not as easy to see what versions of IP we are using:

Our manager prefers #2 because it is easiest for him to look at a client spec and know all the IPs we are using and the versions. The worker bees tend to strongly dislike this one as it means we have to try and keep everyones individual client specs up to date and is not under SCM of the project itself.

How do others handle IP within a Perforce project and what recommendations do you have?

UPDATE:

I am really leaning towards solution #3, it just seems so much cleaner and easier to maintain. If any one can think of why #3 is not a good idea please let me know.

---

I would go for the third solution too.

I can't think of any downsides, and have not experienced any when faced with similar situations in the past.

You could placate your manager by using a branch spec that clearly spells out which IP versions are branched in. He could then refer to that branch spec instead of a client spec.

Also if you look up 'spec depots' in the help, you can set Perforce up so that it version controls all specs, including branch specs, automatically, which will give you traceability if you alter IP versions.

---

"each team member manages there own client spec (inconsistencies)"

Don't do that. Have the client spec be a file that is checked in to Perforce.

---

I would suggest #2 as it is the most transparent system. Yes it will mean some more work keeping clients up to date, but you can minimize that issue by using template clients.

At my work we use template clients that the devs copy from to keep their clients properly configured. We name this with the pattern "0-PRODUCT-BRANCH" (and sometimes add platform if needed). Then it is a one line command from the command line, or a couple clicks from the GUI to update your client. I send notices to the team whenever the template changes.

Now in my case, template changes don't happen very often. There is maybe a max of 5-6 per year, so the hassle level may be different for you.