It's simple:
You need to get access, then you need to check out a branch, then you need to make changes and test them, then you need check in your changes. If you check things into the stable branch (in which case, you are probably named Jeff Allen), then you sometimes need to merge your changes too.
See? It simple!
Here are some brief notes on how to access Cricket's CVS repository.
First, please review this page, which talks about how to talk to CVS remotely.
To use get access to the CVS repository, you need to:
For more information about all of these steps, see the SourceForge Docs.
If you need to give ssh some options to make it work right, you'll need to use ssh-wrap, which is in the dev-tools module. Read the comments near the start of ssh-wrap to understand how to use it.
Cricket has two branches, a development branch, and a stable branch. Most people will only need to check out the development branch. The only person who should be checking anything into the stable branch is Jeff Allen, but anyone who's interested is welcome to check it out.
To fetch the development branch, use a set of commands like this:
mkdir workspace cd workspace cvs -d:ext:$LOGNAME@cricket.cvs.sourceforge.net:/cvsroot/cricket co -d devel cricket
This will put the tip-of-tree sources to Cricket into a directory named workspace/devel. There you can work on them using the normal CVS techniques.
To fetch the stable branch, use commands like this:
cd workspace cvs -d:ext:$LOGNAME@cricket.cvs.sourceforge.net:/cvsroot/cricket co -r v_1_0_x -d stable cricket
Here's a picture of how things look so far:
start | | v_1_0_x_root | | |\ | \ v_1_0_x | \ \ devel \ tip | v_1_0_x_m0 | stable tip
The system gave me "start" for free, upon importing Cricket. The CVS book recommends putting an "root" tag before making a branch, which is why the "v_1_0_x_root" tag is there. The branch is named "v_1_0_x", since that's where I will be releasing the 1.0.x line of Cricket releases from.
The "v_1_0_x_m0" tag will be used to compute diffs when we are moving changes from the stable version to the development version. After each merge is done, I'll add a new tag (_m1, _m2, etc).
When I make a release on the stable branch, I'll make a tag named v_1_0_0, followed by v_1_0_1, etc.