[p4] Using current directory as client root?

[Jeff A. Bowles]

Do NOT get me wrong. Labels work. Changelists work. Retrieval based on
consistent date/time works if you don't mess up w.r.t. timezones or machine
clock skew.
What I was trying to say, is this:

   "p4 sync" then "compile away" then "label based on #have" is reliable.
   But it invites a question from QA: "can you rebuild from the label? Have
you
   really tried it? Can you prove that it creates the same exact results?"

The sequence:
   "get changelist from 'p4 changes -s submitted -m1'" and then...
   ... "p4 sync to that changelist" and then "compile away"
   answers that question already, with the answer "we know we can
   rebuild from that changelist because that is how the build was made."

A label-based solution, done in that sequence, would be just as reliable,
process-wise.

The "sync-from-head and label based on #have" invites a request for a
separate build, just to validate the process. That's understandable, but can
be avoided.

Don't mistake this for a question about tools. If I did not trust the
Perforce database, I would not use it. Period. It's a question about a
reproducible process, and relies less on trust-of-the-tools.

----
A similar thing I often recommend is, "build the last build for a release,
from the 'patch' line. That way, the objects / class files for the eventual
emergency patch are waiting to be used."

That's so that the QA manager who asks, in the face of an emergency patch,
"what was recompiled," can be told "two files were recompiled" instead of
"two files changed and everything was recompiled, but ... trust us, there
are no other differences."

Good QA folks ask tough questions when they hear "trust me" in a technical
explanation.

   -Jeff Bowles


On Jan 17, 2008 5:22 PM, Dave Lewis <dlewis78731 at gmail.com> wrote:

> On Jan 17, 2008 2:51 PM, Jeff A. Bowles <jab at pobox.com> wrote:
>
> >
> > That is, probably more than anything, why I always suggest "sync to a
> known
> > label or changelist or moment, never to 'latest revision', for a build
> that
> > is to be reproducible." (I realize you can label your client's
> "have-list"
> > after-the-build, but it strikes me as inviting a particularly technical
> > question from QA: how do you know that you can build from that label?
> "You
> > have built and then labeled, so there is no evidence except for your
> faith
> > that it can be done in the other order."  Even a tool as reliable as the
> > Perforce database server still invites such a question.)
>
> Well, if labels don't necessarily work, why would syncing to the known
> changelist work the 2nd time? Who does builds twice (as a matter of
> course) to check that they are repeatable?
>
> If a have list is not necessarily correct, I think there is serious
> trouble.
>
> We synced to a known changelist, and if build was good, made a label,
> and archived the whole build's files.  I never really liked labels,
> but they are more memorable than numbers. Included in the build's
> files were the output from "p4 have", the changelist number, a file
> containing the client spec, label name, and some other stuff I can't
> remember...
>
> I think, of those things, the have list was the most useful.
> Sometimes when files are not found during the build process, its easy
> to determine if they were synced or created during the build using the
> have list.
>
> dave
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com