A developers README for P4DB
Introduction
Abstract
This is a README for P4DB, a CGI based p4 depot browser written by Fredric
Fredricson (fredric@mydata.se)
(One part is written by Bob Sidebotham, no email available).
The README is intended for administrators and others that want to install,
maintain, and possibly contribute to, this sw package. You can read it
anyway if You like but You will probably do quite well without.
More introduction
P4DB (P4 Depot Browser) was created to present information about the contents
in the p4 depot in a nice way. Some CGI's also combine output from two
or more p4 commands. The driving force behind the development has been
my needs as a manager for a software team and the needs for our project
leaders.
The browser was developed for and runs on a Linux/Apache system and
has been tested mainly with Netscape 4 although some of our users use MS
Explorer and no problems has been reported.
History
The application was developed from a depot browser, perfbrowse.perl, made
available by Perforce at http://www.perforce.com/perforce/loadsupp.html#browse
Perfbrowse.perl is written in perl and the author is unknown to
me. Some code from perlbrowse.perl remains in P4DB but most parts are completely
changed. The parts left untouched are the ones that were so good that I
did not understand them.
The idea is also stolen so I can't claim that one.
To view file a script by Bob Sidebotham called
p4pr.perl is used. This script is also made
available by Perforce at
http://www.perforce.com/perforce/loadsupp.html#util (only I made some minor changes and one bug fix).
The reason I started to do this was that I liked perfbrowse.perl
very much but wanted just a little more functionality. I started to add
functionality and it quickly got out of hand. Soon I had a huuuge perl
script that I could no longer maintain. Once I realized that I can write
a perl script that is about 2-4 times the size of the script that I can
maintain I decided to rewrite it all from the start as a set of small,
maintainable, perl scripts. I leave to others to judge if I succeeded in
my mission.
(Maybe I should mention that it took much more time than I anticipated).
Installation
First: Where to install
Other than the obvious, that is somewhere in a http servers CGI path, I
recommend You to set up a http server on Your p4 server and run P4DB
on the server. The main reasons are that it improves response time and
reduces load on network.
One argument against this may be that You want to keep Your server clear
from other apps that might create problems. Personally I don't think this
is a very good one but this is up to You.
How to install
You obviously got to this README. Together with README.html file You got
a file "install.pl".
Type "perl install.pl" To install all scripts. This is the
theory, at least. I have not tested it on many systems
Install will first find out if You have CGI.pm installed and if not
a copy will be unpacked. Second it will find out the path to perl, unpack
all cgi scripts and modify the first line to contain the local path to
perl.
For more details, see the comments inside the install.pl
scripts.
How to configure
You will need to configure the scripts. The basic configuration file is
called config. To create a configuration file copy the file config.org
to config and modify it.
The configuration file is a perl script but very little knowledge of
perl should be required to configure it.
To make some handy shortcuts available for the users there is a file
called CODELINES. See the sample file CODELINES.sample.
Before You start
To make sure everything works smoothly You will probably need to manually
run the dtb_update.pl perl script once. This
script creates some data files used to accelerate the "Browse Depot Tree"
function.
Warranty
If You get any problems because of these scripts I promise to feel sorry
for You. Other than that you are on Your own.
Known Bugs
Deleted files can't be viewed
A serious case of feature-bloat
Should probably be written in Java or some other language
Sometimes slow.....
Would You like to contribute?
If You would like to contribute changes/improvements/new functions feel
free to do so and mail them to me and I will add them to the next "release"
(flames and flattery are also welcome).
Disclaimer: I may grow tired of this project or change job or
die or something in which case my promise above probably expires.
What would be a contribution?
I will be glad for any kind of contributions ranging from corrections of
my bad English to new interesting functionality. Nice letters are also
welcome.
Design documentation
The most important documentation is in the P4CGI.pm module. This modules
is used by all scripts and contains a set of common functions that are
a) useful or b) defines some common "look and feel" or c) both.
The P4CGI.pm module is documented using perlpod (see perlpod man page).
To get a HTML page containing documentation type:
pod2html P4CGI.pm >P4CGI.html
(There is one distributed with P4DB, for convenience)
For other files: more often than not the code is commented.
There are five different files 'types' in the design:
-
P4CGI.pm
-
- A perl module containing functions that I
find useful and all other scripts use
-
*.cgi
-
- A set of cgi scripts that are used as ...eh.. cgi-scripts.
-
*.pl
-
- Perl scripts that usually updates temporary data files. These scripts
does not generate HTML output. (so far there is only one such script)
-
/tmp/...
-
- A set of temporary files that contain preformatted data to make access
times acceptable.
-
p4pr.perl
-
- The script by Bob Sidebotham I mentioner earlier
NOTE! The P4CGI.pm module "knows" if it is used in a cgi script or a regular
perl script by checking for .cgi extension.
The code also uses the CGI.pm perl module. This module should be part
of the "standard distribution" of perl (if there is such a thing). On my
target system it was not available so I included a copy with the rest of
the script.
As a part of my personal religion the -w flag is always turned on and
'use strict' flag is also set. I have never had any reason to regret this
particular peculiarity of mine.
Performance has not been a great issue. I assume that these cgi's will
not have thousands of hits each day and the design has focused on ease
of development rather than speed.