P4rubylib

From Perforce Workshop
Jump to: navigation, search

Contents

Introduction

I've started to put together some commonly used/requested scripts both to provide examples of good scripting using P4Ruby and also to solve some common problems in what I hope is an efficient way.

I hope that over time, this will grow into a fairly broad range of resources for Perforce users.

All of these scripts require you to install Ruby and P4Ruby

Support

If you have any problems or questions with these scripts you can contact me at tony@perforce.com or tony@smee.org. These scripts are not supported by Perforce Software, but by me personally. I'll answer questions as quickly as I can.

Triggers

These are some example trigger scripts. The documentation for all of these scripts is available here.


Common Files
P4Triggers.rb A generalised framework for implementing Perforce triggers used by all of the other scripts. If you're going to use these scripts at all, you'll need this file to be installed in the same directory as the scripts themselves.
Pre-Submit Triggers
checkjob.rb Ensures that all changelists are associated with a job before they can be submitted. This is the simplest example of using the P4Triggers.rb framework.
checktype.rb Ensures that new files being added/branched have the correct Perforce filetypes. Whilst "p4 typemap" goes a long way towards ensuring filetype consistency, it's easily overridden. Since a user cannot override a trigger, sysadmins who want more enforcement may want to use this trigger.
checkcase.rb Script to ensure that new files being added/branched respect the case of existing directories in the path. For example, if //depot/test/fileA already exists, then this script will reject an attempt to add //depot/TEST/fileB or //Depot/test/fileB for that matter.

This is very useful if you have Windows clients or if your Perforce server runs on Windows. In an all Unix environment it's not so much of a problem.

Post-Submit (Commit) Triggers (2004.2 and later)
autointeg.rb A script for keeping a slave branch in sync with its master. Whenever a change is submitted to the master branch, it's automatically propagated to the slave via this commit trigger. The files that are integrated can be limited both by the trigger spec, and by the branch spec used.
Spec Triggers
defaultclient.rb A small script to ensure that the default client view for all new clients that are created are based on the view of an existing template client. This allows system administrators to define a default client mapping only a small section of the depot, and by default that's all new users will see when they create their clients.

General Purpose Scripts

These are some useful non-trigger scripts

integrename.rb A script to integrate changes using a branch view and attempt to follow renames in both the source and target branches.
oldclients.rb A script to find the oldest <n> clients - useful to locate candidates for deletion.
reversechange.rb A script to back out a specified change. Handles many cases, but may be defeated by older changes. See the notes in the script for more information.

Additional Information

Recent Changes RssIcon.gif

  • Change 7564 tony_smith@tony_smith-barney-public
      Bug fix: when a rename is pure the script would still delete the
      target file instead of leaving it alone. We really only need to handle
      integrates where the content of the file changes - pure name changes
      in the source are not an issue for us since the whole point of the
      script is not to propagate them.
      This change ensures that in the case of a file branched due to a
      rename, the branch and the associated delete are both reverted.
      Also took out the -I flag to integ, which is archaic now.
  • Change 6437 tony_smith@tony_smith-barney-public
      Update P4Ruby Library scripts to support Perforce P4Ruby 2007.3
      rather than my old public depot P4Ruby.
  • Change 5881 tony_smith@tony_smith-barney-public
      Optimizations for checkcase.rb: add caching for path lookups so
      we don't end up looking up the same directory more than once. Also
      include negative lookups - those where no matching path was
      found in the cache. This brings the overhead of check new, large
      branches down to a few commands.
  • Change 5854 tony_smith@tony_smith-barney-public
      Bug fix: checking the case of files was broken because of clumsy
      re-use of a variable name in the mismatch_depot method. Thanks to
      Markus Spies at IDS Scheer.
  • Change 5837 tony_smith@tony_smith-barney-public
      Add support for branches downgraded to add in integrename.rb
      (thanks to Martin Gamwell Davids). Also added some code to output
      the detected mappings so they can be added to the branch view. The
      script doesn't add them automatically since it's complicated to work
      out which side of the view the source/dest paths should be and the
      user may not want the entries added anyway. At least this way, they
      can see what they are.

License

Copyright (c) 1997-2007, Perforce Software, Inc. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL PERFORCE SOFTWARE, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.