[p4] Advice on Client Specs - ste...@vance.com - com.perforce.perforce-user

7 messages in com.perforce.perforce-user[p4] Advice on Client Specs

From	Sent On	Attachments
Greg Whitfield	12 Jul 2001 07:19
Chuck Karish	12 Jul 2001 11:46
Stephen Vance	12 Jul 2001 18:17
Simon Morton	13 Jul 2001 09:10
Dave Lewis	13 Jul 2001 09:28
Gordon Broom	13 Jul 2001 09:55
ste...@vance.com	13 Jul 2001 14:40

Subject:	[p4] Advice on Client Specs
From:	ste...@vance.com (ste...@vance.com)
Date:	07/13/2001 02:40:29 PM
List:	com.perforce.perforce-user

Versioning the client specs is not a bad way to manage it. The big caveat is that you don't want to store it in the same branching structure as your source code. Then you get into the catch-22 of "I need a client spec to find my client spec." Putting them into a fairly flat administrative branching structure is better. Other development process artifacts, sometimes including process documents, requirements and design documents, etc. also should be classified similarly. That said, you *will* need to either branch the client spec for a release build into the source tree, label it along with the release, or use some other form of configuration record (such as wherever you record compiler version, OS version, etc.) to know which specs apply to which release so you can reconstruct it properly.

Steve

How do people manage change in client specs? Changing a client spec is a great way to break all previous builds. Ideally you need to version the client spec along with source code but this generates a circular reference, i.e. you need the client spec to get the right version of the client spec. I haven't done this but I envision having a "bootstrap" client spec that would be used by the build script to fetch the appropriate project client spec for a given change # or label and set it in the build view before syncing.

How do other folks deal with this issue?

Simon

-----Original Message----- From: Stephen Vance [mailto:steve at vance.com] Sent: Thursday, July 12, 2001 9:18 PM To: Greg Whitfield; 'perforce-user at perforce.com' Subject: Re: [p4] Advice on Client Specs

At 03:20 PM 7/12/2001 +0100, Greg Whitfield wrote:

We are just doing a pilot project to change over a

complex

code base from

Visual Source Safe to Perforce. The concept of Client Specifications/Views/Workspaces (what *are* the differences?) seems very powerful, but we have been trying to work out good

practice for them.

Chuck gave a good description, so I won't repeat.

More specifically, would it be usual to have a single

client

spec that you

work with most/all of the time, or multiple specs that you switch repeatedly?

I tend to advocate a client-per-significant project approach.

The question arose because we were trying to work out

how

the Visual C++

plugin knows to tie a project on your disk to a

particular

depot location.

It looks like this is done via the Default Client

Spec,

which you can set in

P4Win - but which is different from the "current"

(i.e..

switched-to) client

spec in P4Win.

I believe you can get around this by using the P4CONFIG setting. First, you do 'p4 set P4CONFIG=p4config'. Then you put a file called 'p4config' at the client root that contains the Perforce variable settings you need for the particular client. From then on, when you switch projects, you switch locations in the local disk space, which gets the correct config settings. I forget with certainty whether this works for the VC++ plug-in, but I think it does. Can anyone confirm or deny?

It will still be up to the developer to make sure P4Win is working on the same client as VC++.

So, anyone got any advice on best practices for client specs? I know its is a hugely generalised question - that is half the problem :)

Greg ~~~~

user

Stephen Vance mailto:steve at vance.com http://www.vance.com/

--------------------------------------------- This message was sent using WebMail by CyberGate. http://www.valueweb.net/webmail