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

[Chuck Karish]

On Jan 7, 2008 8:04 AM, Ivey, William <william_ivey at bmc.com> wrote:
> >From the OP's messages, I assumed he was referring to development
> builds,  not releases.
>
> -Wm

Did you miss this, from the original post?

> What is a good strategy for identifying the code set that goes into
> version 1.1?

  Chuck



> 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.

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