Each project hosted on Puszcza is assigned a web space available from the following URL:
In this example as well as in the discussion below, project stands for the actual UNIX name of your project.
To populate the webspace with the actual content, it must be checked in to the CVS repository cvs.gnu.org.ua/webcvs/project/project. The recommended way to do so, is described below.
For the initial check in, change to the directory containing the web content for your project and run the following command:
CVS_RSH=/usr/bin/ssh cvs -d :ext:cvs.gnu.org.ua/webcvs/project import -m 'Initial import' project project start
The web space will be synchronized with the checked in files within 2 seconds after the import.
It might be a good idea to have the following statements added to your .profile:
CVS_RSH=/usr/bin/ssh export CVS_RSH
That way you won't have to set CVS_RSH before each invocation of cvs. In the rest of this article we assume you already have these statements in your .profile.
After running initial import, remove or move away your working directory and check it out from the repository with the following command:
cvs -d :ext:cvs.gnu.org.ua/webcvs/project co project
Another way to do initial import is to check out the empty repository first (using the command above), populate it with the files, run cvs add and commit the changes using cvs commit.
Whatever method you use for initial import, you will end up with your content available via http and a local copy of the working tree. If you wish to modify the content later, do the necessary changes to your local copy and commit them. Use cvs add to add a file or directory. Use cvs update -P before you commit a file, and cvs commit to perform the commit. Committed changes become visible on www.gnu.org.ua within 2 seconds after the commit. For further details on cvs, such as reverting to a previous version, or getting a diff output of particular changes, see the CVS documentation.
The .checkoutrc file
Due to security reasons, any .htaccess files are removed during synchronization. However, special provisions are made to allow you to control the way httpd handles your files. Special files named .checkoutrc can be included in the commit. When encountered, such files are treated as lists of commands to be performed after checking out the changes.
When parsing a .checkoutrc file, empty lines and lines beginning with a # sign are ignored. Generally speaking, the # sign introduces a comment, unless it appears within a quoted string or is escaped using the backslash character. All material starting at that sign and up to the end of the line is ignored.
Each non-emtpy line from a .checkoutrc is split into words using algorithm similar to the one used by Bourne shell. The first word is a command verb and the rest of words are its arguments. Command verbs are case-insensitive. Available commands are:
- link src dst
- Creates a symbolic link from src to dst. Neither argument can be an absolute pathname or contain references to the parent directory.
- unlink file
- Unlink the file. The argument must refer to a file in the current directory or one of its subdirectories, that is either a symbolic link to another file or to .htaccess file.
- chmod mode file [file...]
Change mode of the listed files to mode, which must be an octal number. Shell wildcards are allowed in file arguments. After expanding, each file argument must refer to a file in the current directory or one of its subdirectories.
The following statements cause creation of a .htaccess file. It is created in the same directory as the .checkoutrc file being processed.
- xbithack on|off
- If set to on, enables the Apache XBitHack.
- ssi on|off
If set to on, enables server-side includes, by adding the following statement to the .htaccess file:
AddHandler server-parsed .html
The following statements are reproduced in .htaccess verbatim:
- redirect args...
- rewritebase args...
- rewritecond args...
- rewriteengine args...
- rewritemap args...
- rewriteoptions args...
- rewriterule args...