[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