[p4] RCS keywords

Krzysztof Kozminski kk at kozminski.com
Fri Nov 10 21:13:52 PST 2006

You're correct, extra files would not be discovered with my original  

Note that nobody should be allowed to do any hacking, editing, etc,  
in the build area.  All that ever should happen there is  
synchronization of the files to the versions that should go into the  
build. It is also a good idea to keep the sources and the products of  
the build in separate directories. In such situation, the output of  
the following command in the source directory will identify the extra  

   find . -type f -o -type l | sed 's/$/#have/' | p4 -x - files \
      | grep 'no such file' > unauthorized_additions

The extra stuff will be reported with a comment like this:

    ./stuff#have - no such file(s).


On Nov 10, 2006, at 6:09 PM, Jeff Grills wrote:

> 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

More information about the perforce-user mailing list