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

[Ivey, William]

I see where your confusion came from, there are two issues in this
thread, the first is identifying the contents of a given version,
the second, which is what I was addressing, was how to efficiently
handle switching between them for development purposes. (If he
meant for release builds, that wasn't explicit. There is certainly
even less reason to do tricks to save drive space on an official
release build system.)

The OP explicitly wanted a mechanism akin to that in Subversion.

-Wm

-----Original Message-----
From: Chuck Karish [mailto:chuck.karish at gmail.com] 
Sent: Monday, January 07, 2008 11:07 PM
To: Ivey, William
Cc: Jeff A. Bowles; Perforce Users
Subject: Re: [p4] How do YOU identify the code set for a release?

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