[p4] perforce-user Digest, Vol 23, Issue 9

Chuck Karish chuck.karish at gmail.com
Mon Nov 13 08:52:13 PST 2006


My feeling is that the old build area should be irrelevant.
One can save stripped and unstripped copies of one's
binaries and record the changelist or label at which the
workspace can be reproduced.

Excluding users from the workspace where an automated
build happens is pretty important.  Even if they don't hack
at the files there, every once in a while having someone
leave a window open with CWD in the tree breaks the
"make clean" step of a build.  If users don't interfere and if
the build toools don't write into your source tree, incremental
syncs work fine.

  Chuck

On 11/13/06, Smith, Jeff <jsmith at medplus.com> wrote:
> I'd have to disagree.  I am also a proponent of clean integration
> builds.  We don't even build in the same directory every time.  Our
> build tools start by creating an empty directory and generating the
> build there starting with a p4 sync.  This yields two critical benefits:
>
> 1. The old build area is still around for diagnosing issues that QA may
> believe are build related.
>
> 2. There can be a temptation under pressure to change a build area to
> fix a build without reflecting those changes in the repository.  If you
> keep building in the same area, it's possible for these changes to get
> overlooked.
>
> When it comes to good SCM practices, disk-waste and speed are of
> secondary consideration to reproducibility and traceability.
>
> Jeff S.
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jeff Grills
> Sent: Saturday, November 11, 2006 9:30 PM
> To: 'Slava Imeshev'; perforce-user at perforce.com
> Subject: Re: [p4] perforce-user Digest, Vol 23, Issue 9
>
>
>
> That sounds like you're advocating wiping the local copy and resyncing
> everything from perforce.  Isn't that highly wasteful, and also
> potentially significantly slower?  I've seen depots with 100,000+ files
> and over 4gb of data - I wouldn't want to resync that from scratch every
> time.
>
> I personally also like the extra protection (whether real or imagined)
> of having the files compared against their MD5 signatures to make sure
> that they transferred to the client correctly, something you don't get
> with just a wipe and a resync.
>
> j
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Slava Imeshev
> Sent: Saturday, November 11, 2006 12:11 AM
> To: perforce-user at perforce.com
> Subject: Re: [p4] perforce-user Digest, Vol 23, Issue 9
>
>
> ----- Original Message -----
> From: "Jeff Grills" <jgrills at drivensnow.org>
> To: "'Krzysztof Kozminski'" <kk at kozminski.com>;
> <perforce-user at perforce.com>
> Sent: Friday, November 10, 2006 6:09 PM
> Subject: Re: [p4] perforce-user Digest, Vol 23, Issue 9
>
>
> > I'd fully recommend at least the following for a real production
> > environment.
>
> In the environment where a build performed automatically on a
> separate build management server nothing of this should be
> happening.
>
> Normally a production build runs against a clean directory
> structure where a simple p4 sync is done to populate it.
>
> Just my 5c.
>
> Regards,
>
> Slava Imeshev
>
> > One important thing that the following instructions don't catch is
> > extra files that perforce knows nothing about.
> >
> > j
> >
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


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



More information about the perforce-user mailing list