11 messages in com.perforce.perforce-user[p4] build scripts
FromSent OnAttachments
Usha Rajesh18 Jun 2001 16:34 
Jeff A. Bowles18 Jun 2001 17:19 
Rick Macdonald18 Jun 2001 20:09 
Jeff A. Bowles18 Jun 2001 20:59 
Chuck Karish18 Jun 2001 21:26 
Paul C. Pharr18 Jun 2001 21:35 
Dave Lewis19 Jun 2001 07:56 
Rick Macdonald19 Jun 2001 08:19 
Ines Heinz19 Jun 2001 08:54 
Ines Heinz19 Jun 2001 09:00 
Stephen Vance19 Jun 2001 19:59 
Subject:[p4] build scripts
From:Chuck Karish (kar@well.com)
Date:06/18/2001 09:26:41 PM
List:com.perforce.perforce-user

(Disclaimer: I'm not Jeff.)

At 09:09 PM 6/18/2001 -0600, Rick Macdonald wrote:

On Mon, 18 Jun 2001, Jeff A. Bowles wrote:

p4 sync "#none" # the quotes are because rm -rf $WorkspaceArea

Jeff - every time you suggest this I'm tempted to ask you about it. This time I will!

Syncing to none and clearing the workspace (daily?) kinda implies superstition, or mistrust of people, software and/or systems (build scripts, makefiles, dependencies, or something).

You bet.

Either that or simply the actions of a busy guy who'd rather just be safe and never bothered.

That, too.

Or, ...what? A few words of support for this would be interesting and educational.

...RickM...

A developer can pound away at the files in his or her own workspace until the code works, then check it in knowing that the functionality has been implemented.

The release engineer's task is a little bit different: to make sure that the engineer's intent is faithfully stored in the code repository and that it can be built starting with a blank slate. Someone who builds over and over in the same sandbox may not notice that the build depends on a file that happens to be there because a "clean" target doesn't remove it.

Building in a fresh, clean client workspace helps ensure that all developers will be able to build in their own workspaces. Testing against such builds guarantees that the required behavior is actually implemented by changes stored in the depot.

-- Chuck Karish karish at well.com (415) 317-0182