SciTech uses the commercial Perforce version
management software to maintain it's public Open Source software
repository. Perforce Software has graciously allowed Open
Source software projects to be able to use a free server license
for that source code.
Download a Perforce Client In order to get Perforce up and running
on your system, you will need to download the Perforce client
program for your OS. Perforce Software provides clients for
just about every OS freely on their web site at:
http://www.perforce.com/perforce/loadprog.html
All you need to do is download the appropriate 'p4' binary
for your OS from their web site. You may also want to download
or browse the documentation for p4, although it is quite simple
to use from the command line and has extensive command line
help.
Note: If you have not upgraded recently you should upgrade
your copy of Perforce to the latest 2000.1 edition which has
some new features that our Perforce server supports. However
our depot should work with most Perforce clients right back
to the 97.x series.
In order to use Perforce you will need a TCP/IP connection
to the internet, either via modem or direct connect. Accessing
Perforce via modem is actually quite fast, and we have successfully
done remote development over a 28K modem line.
Setting up your environment
for anonymous access:
Once you have downloaded the P4 binary and put it on your
path, you want to set the following environment variables:
P4PORT
P4USER
P4PASSWD
P4CLIENT
P4EDITOR
=
=
=
=
=
perforce.scitechsoft.com:3488
anonymous
anonymous
YOURNAME_YOURMACHINE_YOUROS
(path to your favorite console editor, such as vi)
where you would replace YOURNAME_YOURMACHINE_YOUROS
with a unique name (you can't use a client that someone else
is already using anonymously!). For instance a valid client
name might be: JOEBLOGGS_DEVEL_LINUX
The client names the view that maintains the information about
what files you have checked out on that system, and it must
be unique for each user, and each machine. If you are doing
development under multiple OS'es or multiple machines, you need
a separate client view for each machine and each OS that will
contain a copy of the source code from Perforce (hence the above
naming convention for clients).
Once you have the above variables set up, you can see if Perforce
can access our server by typing the following:
p4 info
You should see something similar to the following if it can
connect successfully:
User name: KendallB
Client name: KENDALLB
Client host: KENDALLB
Client root: c:\
Current directory: c:\private\src\graphics\drivers\mgag200
Client address: 63.195.2.100:3643
Server address: perforce.scitechsoft.com:3488
Server root: /home/perforce
Server date: 2000/12/17 16:21:08 PST
Server version: P4D/LINUX52X86/2000.1/17250 (2000/09/11)
Server license: SciTech Software 58 users (support ends 2001/06/21)
Setting up your client mapping: Once you are are able to connect, you need
to set up your client mapping since by default it will be empty.
The client space is what allows you to map in only the portions
of the software respository that you care about, and where to
put them on your local system. The client information is then
stored remotely on our server so it knows what files you have
on your system and where they live (so if you delete stuff manually
you will need to do a forced sync!).
To set up your client mapping,
type:
p4 client
which will bring you into your editor of
choice. It will include comments at the top about what the part
of the file are used for. There are two parts that you need
to modify; the 'root' definition and the 'view' definition.
The 'root' is the root directory where all files get checked
out onto your system, and this should be the root of the scitech
directory (ie: /home/KendallB/scitech is where I put the MGL
sources on Unix systems, or c:\scitech for DOS/Windows/OS2 systems).
For example:
Root: /home/KendallB/scitech
The 'options' defines what options are in effect for that client.
The most important one you will want to change is the 'nocompress'
option to 'compress'. By enabling compression, you will drastically
reduce the time required for syncs over an internet connection!
The 'view' defines what parts of the perforce repository you
want mapped to your local drive. The simplest mapping which
will pull down all the MGL files you would need (and the one
you should probably use) would be:
where you would replace the 'YOURNAME_YOURMACHINE_YOUROS' above
with the name of your client. This line indicates that all files
get mapped to the /home/KendallB/scitech directory and all subdirectories
under this (like src, include, examples etc). Note that to save
download times, we do not include any of the bitmaps, fonts
and other large resources in the anonymous user account, so
you will need to unzip those from the official beta release
files. Now once you have the client view defined, exit your
editor and it will send the changes to the perforce server.
Syncing
up for the first time: The SciTech Perforce software respository
contains a lot of code, and doing a full sync will pull down
well in excess of 10 meg of files. Hence in order to save time
for the initial sync, you can download and install all the files
from the latest beta release of the software to your system,
and then tell Perforce that you have all files at the time that
build was made. Then when you sync up you will only pull down
all the files that have changed since the last official beta
release.
For example, to do the initial sync for SciTech MGL, use the
following commands:
p4 flush -f @mgl5.0_beta5
p4 sync
to tell Perforce that you have all the files at the label 'mgl5.0
_beta5' (change mgl5.0_beta5 to the label appropriate for the
beta release you have downloaded). The 'p4 sync' then grabs
any changes that have occured since the 'mgl5.0_beta5' label
and ZIP files were built. Once you have sync'ed up the first
time, you should only use 'p4 sync' to get the latest updates
to all the files. Using Perforce from the command line: Using Perforce is very easy, and you can
get help from the command line with:
- Sync up with the
latest sources
- Open a file for editing
- Add a new file to the repository
- Delete a file from the repository
- Resolve conflicts if two people edit the same file
- Revert changes for a currently opened file
- Submit all changes to the repository
- List call files you currently have opened
The big difference between Perforce and other
SCM systems like RCS is that Perforce is 'change' oriented.
When you submit a changelist, included in the list will be all
of the files that you currently have opened (if you don't want
a file in that change list, simply delete it from the change
list in the editor and it won't be submited but will remain
in your list of open files are the submit). You *must* provide
a description for the change, and then the entire set of files
associated with the changes is submitted as a single change
to the server, including file additions and deletions! Hence
when you need to revert back to older versions of the code,
you can do it via the revision number for a specific file, a
change list number to go back to the state when a particular
change was submitted, or a label which you defined earlier (SciTech's
build system automatically adds labels for builds so we can
revert all code back to the release code for later testing).
Note that anonymous users only have read access to the software
respository, and will not be able to open any files or submit
changes. If you wish to be able to contribute changes to the
SciTech Perforce repository, contact KendallB@scitechsoft.com
directly and you can get a developer account with read/write
access.
