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

[Jeff Grills]

I'd fully recommend at least the following for a real production
environment.  One important thing that the following instructions don't
catch is extra files that perforce knows nothing about.

j

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Krzysztof Kozminski
Sent: Friday, November 10, 2006 2:05 AM
To: perforce-user at perforce.com
Subject: Re: [p4] perforce-user Digest, Vol 23, Issue 9


[... cut ...]

With Perforce, creating a record of what went into the build, and  
verifying that what was in the build area is indeed what was  
recorded, is trivial:

	p4 files #have > manifest
	p4 diff -sd > unauthorized_deletions
	p4 diff -se > unauthorized_edits
	p4 opened > uncommited_changes

The first file will contain exact record of every version of every  
file in the build area, and the latter three should be empty to  
ensure the consistency. This is done *before* the build, so you don't  
even start building anything that might be inconsistent. Now you  
associate the manifest with the unique build ID, store it  
indefinitely, and all you need in the software is an appropriate  
embedding of the build ID.

The above is just a minor part of what goes into ensuring  
consistency, proper branching discipline being one of much more  
important contributing factors.

KK