# -*-perl-*- # Configuration file for codestriker.pl. # Database to use for storing codestriker data. Examples given are # Oracle, SQL Server, PostgreSQL and MySQL. #$db = 'DBI:Oracle:host=127.0.0.1;sid=local'; $db = 'DBI:ODBC:Codestriker'; #$db = 'DBI:Pg:dbname=codestrikerdb'; #$db = 'DBI:mysql:dbname=codestrikerdb'; # Database user. #$dbuser = 'system'; $dbuser = 'codestriker'; # Database password. #$dbpasswd = 'manager'; $dbpasswd = 'cspasswd'; # Location of the mailing host. This is used when sending out codestriker # comments. $mailhost = 'localhost'; # Indicate whether to try and compress output if the client browser # supports it. This can make a tremendous difference in bandwidth, # especially over slow links. $use_compression = 0; # Location of gzip. Gzip is used only if you don't have Compress::Zlib # installed. Note, if running with mod_perl, you _must_ have Compress:Zlib # installed. If gzip is not available, this can be set to "". $gzip = '/bin/gzip'; # Location of the cvs binary. #$cvs = 'c:/Program Files/GNU/WinCvs 1.3/CVSNT/cvs.exe'; $cvs = '/usr/bin/cvs'; # Location of the ssh binary. This is only required if a CVS :ext # type repository is used. $ssh = '/usr/local/bin/ssh'; # Location of the p4 (Perforce client) binary. This does not need to be set # if you are bot using any Perforce repositories. $p4 = '/usr/local/bin/p4'; # Location of the vss binary. This can be ignored for deployments which don't # use VSS (Visual Source Safe). $vss = 'C:/Program Files/Microsoft Visual Studio/VSS/win32/ss.exe'; # Temporary directory Codestriker can use. For *NIX platforms, this will # /tmp by default, for Windows 2000 c:\winnt\temp and for XP, c:\windows\temp. # For Win32 deployments, these temp directories may not be accessible to # the user running IIS or Apache, so explicitly specify an apprioriate # directory here that exists on the system. For *NIX platforms, there is # usually no need to do anything here. #$tmpdir = '/tmp/codestriker'; #$tmpdir = 'c:/codestriker temp'; # If codestriker is installed differently to that described in the README file # (for example on the sourceforge servers), it may be necessary to explicitly # specify the location of the codestriker_css as a URL. $codestriker_css = ''; # The URL to the bug tracking system. The bug number is appended to the # end of this string when URLs are generated. This can be left blank if # there is no need for bug-tracking integration. $bugtracker = ''; #$bugtracker = 'http://localhost.localdomain/show_bug.cgi?id='; # Valid repositories which may be selected at the create topic screen. # The order shown here is the order presented in the option list. Most # deployments will only require a single repository to be specified. # Comment out / modify entries appropriate for your deployment. # # If this list is empty it won't be possible to view the entire contents of a # file before the proposed change and/or after. All of the places # in the application that ask for, or display repository information will # be hidden and lastly, it will be impossible to make a diff review topic # on files that already checked in. @valid_repositories = ( # Example CVSROOT of a CVS repository on the same machine as the # codestriker server. '/home/sits/cvs', # Example of a CVS repository which contains the URL to a viewcvs # installation (CVS web is also supported), followed by the # CVSROOT of the repository. 'http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi /cvsroot', # The next example is the syntax used for specifying a Subversion # repository, which is simply the subversion repository URL # prefixed # by svn: 'svn:http://svn.collab.net/repos/svn/trunk', # Subversion server with authentication. The user name and # password should be added to the end and separated by # semicolons. 'svn:http://svn.collab.net/repos/svn/trunk;username;password', # Example CVS pserver config with username and password # specified. ':pserver:sits:password@cvs.sourceforge.net:/cvsroot', # Example CVS pserver config with proxy options. ':pserver;proxy=abc.com;proxyport=8080:sits:pwd@cvs.dev.net', # Example CVS pserver with empty password. ':pserver:anonymous:@cvs.sourceforge.net:/cvsroot', # Example CVS server which will be connected to with SSH. This # assumes the appropriate ssh keys have been created so that the # process running the Codestriker application can connect to the # CVS server without requiring a password to be entered. ':ext:sits@localhost:/home/sits/cvs', # Visual SourceSafe repository on same machine at default # location. Username "admin", password "password". 'vss:admin;password', # Visual SourceSafe repository on same machine, but with specific # repository location specified. 'vss:c:\\Program Files\\Microsoft Visual Studio\\VSS;admin;password', # Visual SourceSafe repository located on a network fileshare. 'vss:\\\\VisualSourceSafeMachineName\\SharedRepositoryPath;admin;password', # Example Win32 CVS repository on the same machine. ':local:c:\\cvsrep', # Another Win32 CVS repository on the same machine. 'c:/cvsrep2', # The next example is for a Perforce repository. After the # leading :perforce identifier, the next two components are the # Perforce user and client parameters. The last two parameters # after the '@' symbol represent the host and port number of # the Perforce server. 'perforce:sits:sits2@localhost:1666', # The final example is a ClearCase repository, where the path is # the location of a shared snapshot view. From this view, it # should be possible to a file of any version can be # retrieved from the vob using the "cleartool get" command. It # is important that this snapshot view is accessible with the # same path specification for all developers. This is because # a diff file created by a developer will refer to the snapshot # view, and will allow Codestriker to retrieve specific files # and versions mentioned in the review text, when necessary. # It is also important that the user account running the # webserver process has permission to access to the snapshot # view. 'clearcase:c:\\stuff\\view_name\\vob_name' ); # A mapping of repositories to filename viewers. Examples of such systems # would be CVSweb and ViewCVS, for local repositories. Mappings are # not required for remote CVSweb and ViewCVS repositories, as they are # viewers themselves. When viewing reviews, links from filenames will be # mapped to these URLs, to obtain revision log information for that file. $file_viewer = { '/home/sits/cvs' => 'http://localhost/cgi-bin/cvsweb.cgi' }; # Exclude these file types from review topics. # You will generally want to exclude any non-human-readable files. @exclude_file_types = ('rtf', 'doc', 'gif', 'bmp', 'jpeg', 'jpg', 'mdb', 'ppt', 'vsd', 'xls', 'zip', 'tgz', 'tar', 'gz', 'opt', 'aps', 'ncb', 'a', 'so', 'dll', 'lib', 'exe', 'png', 'pdf', 'bin', 'out', 'ld', 'fm', 'indd', 'wav', 'o', 'obj', 'mpp', 'vsw', 'jfif', 'tif', 'tiff', 'xbm', 'fnt', 'ttf', 'pfm', 'pfb', 'eps', 'wpj', 'sxi'); # The number of problems found per line drops if the size of the # topic is too large. A common inspection pitfall is for authors to # attempt to review too much material and then miss problems. # These two options allow the Codestriker administrator to limit # the length of the topics. Topics that have more lines than # $maximum_topic_size_lines are rejected when they are created. # Topics that are larger than $suggested_topic_size_lines generate # a warning displayed in the topic page, but are accepted into the # system. Codestriker measures that length of the topic by counting # the number of lines in the topic text. # # The codestriker default of not enforcing any limits is specified by # settings either option to an empty string. If you are not sure # what a reasonable limit would be, start with a suggested_topic_size_lines # set to 350, and adjust with experience. $maximum_topic_size_lines = ''; $suggested_topic_size_lines = ''; # The default viewing mode to use in the URL when creating a topic. Can # be either ($NORMAL_MODE, $COLOURED_MODE or $COLOURED_MONO_MODE). These # values should not be changed. $NORMAL_MODE = 0; $COLOURED_MODE = 1; $COLOURED_MONO_MODE = 2; $default_topic_create_mode = $COLOURED_MODE; # The default line break viewing mode to use in the URL when viewing a # topic. Can be either $LINE_BREAK_NORMAL_MODE or $LINE_BREAK_ASSIST_MODE. # Using $LINE_BREAK_ASSIST_MODE indicates that extra line breaks may be # used in the topic display if the review has very long code lines. Using # $LINE_BREAK_NORMAL_MODE will ensure that the display matches the line # breaks present in the code. The line break mode can also be changed # dynamically in the view topic screen. There is usually no need to # change this setting unless you regularly review code with very long # lines. $LINE_BREAK_NORMAL_MODE = 1; $LINE_BREAK_ASSIST_MODE = 2; $default_topic_br_mode = $LINE_BREAK_NORMAL_MODE; # When displaying a topic, if this value is -1, then all files in the # topic are displayed in the one page (default old Codestriker # behaviour). If the value is 0, then only the first file is shown, # with links to display the other files. This is useful for those # deployments that review a large amount of code. $default_file_to_view = -1; # List of valid topic states. Note these values are mapped to the database # depending on their position in the list. ie, Open -> 0, Closed -> 1, etc. # There is no problem added new states dynamically, or changing the textual # names. Note, the initial topic state must be the first element. If # the 'Obsoleted' state is removed, then it will not be possible to obsolete # topics. If the 'Deleted' state is removed, then it will not be possible # to delete topics. @topic_states = ('Open', 'Closed', 'Committed', 'Obsoleted', 'Deleted'); # Indicate if topics can be listed/searched. Turning this to false can be # useful for "anonymous" installations of codestriker. $allow_searchlist = 1; # The following controls project configuration. Each Codestriker topic is # a member of a specific project. Uncomment the option you want # below. Note the textual state names below cannot be changed. # Default option, projects are enabled, but they have no state # changing operations (ie, projects are always in state 'Open'). @project_states = ('Open'); # Don't use projects at all. Effectively, an implicit "default # project" is created and associated with all topics behind the scenes. # @project_states = (); # # Allow for projects to be closed. Closing a project will # not allow new topics to be created in that project. # @project_states = ('Open', 'Closed'); # # Allow for projects to be deleted. This is potentially a dangerous # option to allow, as deleting a project will delete all of its member # topics as well. Use with caution. # @project_states = ('Open', 'Deleted'); # # Allow for projects to be closed and deleted. Use with caution. # @project_states = ('Open', 'Closed', 'Deleted'); # If true, don't display any email addresses in their true form, but # truncate them, to beat SPAM harvesters. $antispam_email = 0; # If true, codestriker will send out emails to the topic owner and # comment submitter when a comment is added. If this option is false, # no email will be sent to either the topic owner or the comment # submitter. Emails about each comment may not be needed if a meeting # is planned to discuss the topic. If the comment submitter specifies # a cc user, an email is always sent out, regardless of this setting. $allow_comment_email = 1; # Default width of tabs. Most developers expect this to be 8, but # some expect to see 4. This is also stored in the user's cookie, and # can be changed dynamically on the view topic screen. $default_tabwidth = 8; # Bug database to update. Currently, only Bugzilla is supported, but it is # straight-forward to support other bug databases. To enable bugzilla, set # $bug_db to "bugzilla", and set the following parameters to your setup. # if the $bug_db is an empty string, all bug-tracking related features will # be disabled. $bug_db = ''; #$bug_db = 'bugzilla'; # Bug database connection details. $bug_db_host = 'localhost'; $bug_db_name = 'bugs'; $bug_db_password = 'bugs_password'; $bug_db_dbname = 'bugs'; # Bugzilla codestriker user id. $bug_db_user_id = '2'; # LXR database. Each repository can be optionally mapped to a # different LXR deployment. If a repository has an associated LXR # mapping, then create a new entry where the repository string is the # key, and the value is another map, where "db" is the LXR database # URL, "user" is the database user, "password" is the data password, # and "url" is the base LXR URL for viewing where an identifier is # defined/used. $lxr_map = { # '/home/sits/cvs' => { db => 'DBI:Pg:dbname=lxr', # user => 'lxr', # password => '', # url => 'http://localhost.localdomain/lxr/ident?i=' # }, # # 'svn:http://svn.collab.net/repos/svn/trunk' => # { db => 'DBI:Pg:dbname=lxr2', # user => 'lxr', # password => '', # url => 'http://localhost.localdomain/lxr2/ident?i=' # } }; # Each comment thread (or issue) that is created against a specific # code line in Codestriker can have a configurable number of # user-defined metrics recorded against it. # # Every site has their own requirements, below are a number of example # configurations. The "name" attribute refers to the name of the # metric being recorded. The "values" attribute is a list of values # that this metric can be assigned to. The "default_value" attribute # is optional, and indicates what the default value of the metric is # assigned to. If this attribute is not specified, then the user will # be required to specify a value for a metric when creating a new # comment thread. This is recommended, so that users think about what # these values should be, rather than blindly accepting default # values. For the "Status" metric below however, it is recording the # "state" of the thread, so an initial state of "Submitted" is reasonable. # For the other metrics below, an initial value makes no sense. # Metric items can have an optional show_on_main_page list that will # force the numbers of comments with the metric settings to be reported # on the main page of codestriker. $comment_state_metrics = [ { name => 'Status', values => ['Submitted', 'Invalid', 'Completed'], default_value => 'Submitted', show_on_mainpage => ['Submitted' ] } ]; # Two metrics defined: Status and Type. #$comment_state_metrics = # [ # { name=>'Status', values=>['Submitted', 'Invalid', 'Completed'], # default_value=>'Submitted' }, # { name=>'Type', values=>['Style', 'Minor', 'Major', 'Severe'] } # ]; # # Four metrics defined: Status, Level, Mode and Type. #$comment_state_metrics = # [ # { name=>'Status', values=>['Submitted', 'Invalid', 'Completed'], # default_value=>'Submitted' }, # { name=>'Level', values=>['Major', 'Minor'] }, # { name=>'Mode', values=>['Missing', 'Wrong', 'Unclear', 'Suggestion'] }, # { name=>'Type', values=>['Logic', 'Data Handling', 'Interface', # 'Error Handling', 'Performance', 'Comments', # 'Standards'] } # ]; # # Case where no comment thread metrics are to be used. #$comment_state_metrics = []; # Allows you to override the default title of "Codestriker %version%". # $title = "Codestriker $Codestriker::VERSION"; # This options configures the metric support in codestriker. You have # the following options: # # $metric_config = "none", "basic", "all", "metric name, metric name, etc" # # "none" - turns off all extra metric support in the application. The # metric page will only display and manage data that is strictly # required to perform the review. Codestriker will not require any # addition data input from the reviewers and authors. This is the # default. However, you still get basic data like how many topics are # being created and how problems are being found. # # "basic" - Turns on the metrics that are considered to be essential # for a metric program. It will require that reviewers and authors # enter the time spent reviewing the topic, the time spent in the # review meeting, and the time spent preparing for the review. The # metric selection assumes that you are following a formal review # process with a preparation meeting, and a defect review meeting. # # kickoff time - time spent preparing for the review # checking time - time spent actually reviewing the topic. # logging meeting duration - the time spent in the logging meeting. # # "all" - Turns on all of the metrics that one could possibly want to # track. The list of metrics is from the book "Software Inspection" by # Gilb and Graham. You should probably not use this unless you are # using a formal process that is well established. You may want to # enable this temporally to get a idea of the types of metrics that # are supported. # # "name,name" - Lastly, you can pick and chose what metrics you would # like to enable. just list the metric names in a comma separated # list. You can see all of the build in metrics in the # lib/Codestriker.pm file. For example, if you don't hold a kick off # meeting, and but do hold a logging meeting, the basic option will not # quit fit. You should set the $metric_config as: # $metric_config = "checking time,logging meeting duration". # # If you don't like our choices of metrics, the names, descriptions, # etc feel free to edit the lib/Codestriker.pm. It contains # documentations on how to add your own metrics into codestriker. It # is easy to do, and does not require any coding. $metric_config = "none";