[p4] Using current directory as client root?

[Ivey, William]

You can prove that the source retrieved by the changelist and
the label will be the same simply by syncing two directories and
comparing the contents. (Or the source in a client and the
source retrieved by the label synced to #have, or @client.)

Of course an automatic label set to the changelist # is as
safe as the number is.

Neither guarantees a repeatable build by itself, of course, 
only that the potential for putting what Perforce controls 
accurately onto the system exists. You'd still have to
prove that the build environment (including OS features) had
not changed in a significant way.

-Wm

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Jeff A. Bowles
Sent: Friday, January 18, 2008 2:48 PM

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
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user