[p4] How do YOU identify the code set for a release?

Ivey, William william_ivey at bmc.com
Mon Jan 7 08:04:52 PST 2008


>From the OP's messages, I assumed he was referring to development
builds,

not releases.

 

-Wm

 

________________________________

From: jeff.a.bowles at gmail.com [mailto:jeff.a.bowles at gmail.com] On Behalf
Of Jeff A. Bowles
Sent: Sunday, January 06, 2008 10:05 PM
To: Ivey, William
Cc: Perforce Users
Subject: Re: [p4] How do YOU identify the code set for a release?

 

One of the giant questions is the QA Manager who asks, point-blank, "can
you recreate this release, byte-for-byte, with what is stored in your
source librarian?"

 

The build manager who delivered a release that was created using a full
build and then a few subsequent incremental builds will either have a
complex answer or a really blank look on his face.

 

Neither is terrific. If it's the former, the QA Manager is certainly
encouraged to ask (at least once) for the build-folks to show that
really, truly can be recreated. (If it's the latter, the QA Manager
probably just says, "come back when you have can recreate this.") 

 

I don't bring this up to say that the strategies mentioned in this
thread are technically suspect, but that there is a higher-level
requirement that the business merits. 

 

  -Jeff Bowles

 

On Jan 6, 2008 10:50 AM, Ivey, William <william_ivey at bmc.com > wrote:

 

> but if the local files that do not differ between the branches 
> remain untouched only a partial build will be necessary.

There are build managers that can make decisions like that based
on the file's content rather than a time stamp. That wouldn't
solve the re-sync problem, but it would cut the subsequent build 
times.

 

 



More information about the perforce-user mailing list