__init__(self,
        p4port,
        p4user,
        p4passwd,
        p4client,
        **kwargs)
     (Constructor)
  
   | source code 
     | 
    
  
  
  
    - Parameters:
 
    
        workdir - local directory (relative to the Builder's root) where the tree 
          should be placed 
        mode - the kind of VC operation that is desired:
          
            - 
              'update': specifies that the checkout/update should be 
              performed directly into the workdir. Each build is performed 
              in the same directory, allowing for incremental builds. This 
              minimizes disk space, bandwidth, and CPU time. However, it 
              may encounter problems if the build process does not handle 
              dependencies properly (if you must sometimes do a 'clean 
              build' to make sure everything gets compiled), or if source 
              files are deleted but generated files can influence test 
              behavior (e.g. python's .pyc files), or when source 
              directories are deleted but generated files prevent CVS from 
              removing them. When used with a patched checkout, from a 
              previous buildbot try for instance, it will try to 
              "revert" the changes first and will do a clobber if
              it is unable to get a clean checkout. The behavior is 
              SCM-dependent.
            
 
            - 
              'copy': specifies that the source-controlled workspace should
              be maintained in a separate directory (called the 'copydir'),
              using checkout or update as necessary. For each build, a new 
              workdir is created with a copy of the source tree (rm -rf 
              workdir; cp -R -P -p copydir workdir). This doubles the disk 
              space required, but keeps the bandwidth low (update instead 
              of a full checkout). A full 'clean' build is performed each 
              time.  This avoids any generated-file build problems, but is 
              still occasionally vulnerable to problems such as a CVS 
              repository being manually rearranged (causing CVS errors on 
              update) which are not an issue with a full checkout.
            
 
            - 
              'clobber': specifies that the working directory should be 
              deleted each time, necessitating a full checkout for each 
              build. This insures a clean build off a complete checkout, 
              avoiding any of the problems described above, but is 
              bandwidth intensive, as the whole source tree must be pulled 
              down for each build.
            
 
            - 
              'export': is like 'clobber', except that e.g. the 'cvs 
              export' command is used to create the working directory. This
              command removes all VC metadata files (the CVS/.svn/{arch} 
              directories) from the tree, which is sometimes useful for 
              creating source tarballs (to avoid including the metadata in 
              the tar file). Not all VC systems support export.
            
 
            
        alwaysUseLatest - whether to always update to the most recent available sources for
          this build.
          Normally the Source step asks its Build for a list of all 
          Changes that are supposed to go into the build, then computes a 
          'source stamp' (revision number or timestamp) that will cause 
          exactly that set of changes to be present in the checked out 
          tree. This is turned into, e.g., 'cvs update -D timestamp', or 
          'svn update -r revnum'. If alwaysUseLatest=True, bypass this 
          computation and always update to the latest available sources for
          each build. 
          The source stamp helps avoid a race condition in which someone
          commits a change after the master has decided to start a build 
          but before the slave finishes checking out the sources. At best 
          this results in a build which contains more changes than the 
          buildmaster thinks it has (possibly resulting in the wrong person
          taking the blame for any problems that result), at worst is can 
          result in an incoherent set of sources (splitting a non-atomic 
          commit) which may not build at all.  
        retry - if provided, VC update failures are re-attempted up to REPEATS 
          times, with DELAY seconds between each attempt. Some users have 
          slaves with poor connectivity to their VC repository, and they 
          say that up to 80% of their build failures are due to transient 
          network failures that could be handled by simply retrying a 
          couple times. 
      
    - Overrides:
        process.buildstep.BuildStep.__init__
    
 
   
 |