This file has some information on how to get access
to the latest PDL sources (mainly of interest
for potential developers). This should not be confused
with the latest public release which will always
be available from CPAN (if you don't know what that
is check the FAQ).
Public CVS repository at www.sourceforge.org
--------------------------------------------
From version PDL-2.003 onwards the source distribution is
in a publicly accessible CVS repository. The project is
hosted at the sourceforge site at
http://www.sourceforge.org/project/?form_grp=612
Starting from that URL you will find directions on how to check
out the current sources, browse the CVS repository online, etc.
If you would like to actively contribute to PDL development
don't hesitate to contact one of the project admins (listed
at the above URL) to apply for write access to the repository.
We strongly believe in the power of open source development!
If you do not know how to use CVS try 'man cvs' or 'info cvs'
and/or have a look at some of the online tutorials available
on the web. A nice concise one is at
http://www.cyclic.com/cvs/doc-blandy-text.html
Very good and complete is the online version of the CVS book at
http://cvsbook.red-bean.com/cvsbook.html
PDL Developer Guidelines:
-------------------------
The following guidelines are for any developer that has access
to the PDL CVS repository.
1) Before committing a change to the repository you should update:
- CHANGES file with a description of the change made.
- MANIFEST (using 'make manifest'), MANIFEST.SKIP, TODO files
if applicable.
2) Remember to include POD documentation for any functions you add to
the distribution.
- See Basic/Core/Core.pm for an example of
including POD documentation in .pm files.
- See Basic/Core/Primitive/Primitive.pd for
an example of including POD documentation
in PDL .pd files.
- read the documentation in PDL::Doc for a detailed
description of the PDL documentation conventions
2) Make sure you add a test case in the 't' directory for any
significant additional capability you add to the PDL
package.
3) Don't commit before you successfully built and passed
'make test'. But then again, don't keep your changes
private for too long to avoid conflicts with other
developers.
4) Bugs reported on the list should be entered into the bug
database and bugs closed when a patch has been committed as
a fix. (Primary responsibility for this task is the pumpking,
but other devels should be able to help.)
Creating a new CVS branch:
--------------------------
(or how to avoid ridiculous branch names like
'badval_experimental_branchpoint')
This is a first draft, so it may not entirely be correct, and
I've missed out the initial options you'd supply to cvs (or
put in an env variable)
0) see what the current set of tags is:
> cvs status -v Changes
The important part of the output looks like:
Existing Tags:
badval_experimental_branchpoint (branch: 1.76.2)
trid_experimental2 (branch: 1.69.2)
trid_branchpoint2 (revision: 1.69)
etc
The badval_experimental branch wasn't created using the
following rules - I didn't do step 1, so ended up
with a branch name called 'badval_experimental_branchpoint'
when I meant it to be 'badval_experimental'.
1) tag the current CVS with a label to indicate the state of
PDL before the branch:
> cvs tag make-cup-of-tea_experimental_branchpoint
(this is the step I didn't do above)
2) create a branchpoint
> cvs tag -b make_cup_of_tea_experimental
3) you can then either check out a new version, using this branch
> cvs co -d PDL.tea -r make-cup-of-tea_experimental PDL
this creates a directory PDL.tea/ and stores the files there,
or convert a current version
> cvs update -r make-cup-of-tea_experimental
As I haven't yet closed a branch, I can't tell you how! The online
CVS documentation (eg http://cvsbook.red-bean.com/cvsbook.html) is
pretty good.