Coppermine Photo Gallery v1.5.x: Documentation and Manual

Table of Contents


As Coppermine is a community effort, with various developers working on it simultaneously, there is the need to have a tool that allows the developers to organize their submissions.

Subversion (SVN) is a version control system initiated in 1999 by CollabNet Inc that is used to maintain current and historical versions of files such as source code, web pages, and documentation.

Target audience

This part of the documentation is not meant for end users of Coppermine, meaning: you don't have to read this nor do you (as end user) have to check out the Subversion repository. However: if you know your way around in Coppermine and would like to see the bleeding edge of Coppermine technology, you're welcome to read this page and check out Coppermine using Subversion access. Primary target audience for this page are coppermine developers though.


As suggested in the testing docs, you (as an end user) are welcome to check out the development versions of Coppermine. However, you have to understand that both subversion access as well as development versions go completely, utterly unsupported.

What is subversion?

Subversion is a revision control system which allows computer software to be developed in an incremental and controlled fashion by a distributed group of programmers. Also commonly referred to as svn or SVN, Subversion is designed specifically to be a modern replacement for CVS [definition]. Subversion was created by CollabNet, who still maintain the project.

SVN provides the means to store not only the current version of a piece of source code, but a record of all changes (and who made those changes) that have occurred to that source code. Use of SVN is particularly common on projects with multiple developers, since SVN ensures changes made by one developer are not accidentally removed when another developer posts their changes to the source tree.

Where is the subversion repository hosted?

Setting up and maintaining a subversion server is something that you can't accomplish on a "regular" webserver (on shared webhosting). That's why the Coppermine group has decided to host the subversion repository at, who provide hosting and services for many open source projects. Originally, the Coppermine project started using Sourceforge's CVS services and later moved to SVN.

Recommended software

Alternative access using Web SVN

For those who don't want to download and install a full SVN client software there is also a usefull tool available called "Web SVN", where the subversion server provides a web-driven interface to browse the structure of the SVN repository. This interface gives you the opportunity to download a tarball archive of the repository, and you can download or view individual files as well. You can not commit your changes with it, so it's no use for developers. You're encouraged to use web SVN first and if you feel familiar with that go for the "real" svn client.

Repository structure

The coppermine SVN root resides in
Within this section you will find several folders: the "trunk" folder contains the mainstream folders of the existing coppermine versions. In the "branches" folder, there are copies of the mainstream versions that are being created as a fork of the mainstream versions, used by particular developers or groups that need control over the structure for a longer period (e.g. during the "summer of code"-stage) to add in-depth changes.

Coppermine Subversion repository

Coppermine core files

The most recent version of the Coppermine package for cpg1.5.x resides in the repository structure under, i.e. it is available via web SVN over


The most recent version of the plugins for cpg1.5.x that are being maintained in the subversion repository (not all plugins are under version management) resides in the repository structure under, i.e. it is available via web SVN over

When downloading a tarball archive of a particular plugin, please understand that the difference between a zip download of a plugin from the download repository and a tarball download from the subversion repository mainly lies in the structure: in the zip file, there should be a folder that you need to upload to the plugins folders of your gallery. The tarball on the other hand doesn't reside in a folder, so you have to create that folder within the plugins folder first. You can not name it as you want to: instead, you need to preserve the name that the folder has got in the subversion repository.

If you are downloading a tarball from the folder, you need to manually create a folder (using your FTP app) named coffee_maker in http://yoursite.tld/your_coppermine_folder/plugins/. Then, after having created http://yoursite.tld/your_coppermine_folder/plugins/coffee_maker you can upload the contents of the tarball into that folder.

To make this absolutely clear: you mustn't rename the folder a plugin resides in at will, and you mustn't name it as you like when using subversion checkouts. The code of the plugin usually contains hard-coded reference to the folder it resides in, so you need to strictly obey to the naming scheme. Your gallery's visitors won't notice anyway, so why should you care how the name of a particular plugin is. The naming scheme is case-sensitive (i.e. capitalization does matter).

Need more examples? Here are some examples from real world plugins:
Name Web SVN Tarball download Folder name
BBcode-control [...]coppermine/branches/cpg1.5.x/plugins/bbcode_control/ [...]/coppermine/branches/cpg1.5.x/plugins/bbcode_control.tar.gz?view=tar bbcode_control
EnlargeIt! [...]coppermine/branches/cpg1.5.x/plugins/enlargeit/ [...]/coppermine/branches/cpg1.5.x/plugins/enlargeit.tar.gz?view=tar enlargeit
Show all videos in flash player [...]coppermine/branches/cpg1.5.x/plugins/video2flash_ffmpeg/ [...]/coppermine/branches/cpg1.5.x/plugins/video2flash_ffmpeg.tar.gz?view=tar video2flash_ffmpeg
You get the point, don't you? It's absolutely mandatory to put the content of the tarball you download into a sub-folder of your plugin folder that is spelled exactly in the way that the folder in the subversion repository has.

Checking out

The term "checkout" actually stands for "download the files from the repository to your local (working) copy on your client".

Checking out the entire repository

svn co coppermine

Checking out a particular Package

Users interessted in the mainstream development should check out the sub-folders of the "trunk"-folder. For cpg1.5.x, you should check out

Checking out a particular file

If you're interessted in just one particular file (e.g. a language file that didn't exist when you downloaded your coppermine package), you're welcome to use the webSVN interface provided by Just navigate to the file you want and use the download link there.

Refering to files downloaded from the subversion repository

If you are using a subersion checkout for whatever reason and you're posting on the Coppermine support board, do not refer to the Coppermine version number from the file header of the file(s) that you checked out, but refer to the revision number instead.

Is there no single package that I could download instead?

Many end users complain that this sounds too complicated - they ask for a single file that they could download. You have to understand that there are packages for end users - you can get them from the "official" downloads section of the project: download the most recent stable release! Using subversion to check out the development version is only meant for experienced users who are eager to test the unsupported development version. Consider the effort needed to check out using subversion as a ticket that allows you to get the cutting edge of Coppermine. Bottom line: no, there is no single file that you could download instead of checking out the repository.

Download Tarball archives

However, starting only recently (as of 2008-08-28), SourceForge (who are hosting "our" subversion repository) have added a new feature to their web svn: you can download a tarball, which in the end is a snapshot of the current version inside the subversion repository. You can find a link to that tarball at the very bottom of the web svn screen. For the actual cpg1.5.x-trunk, the link to that tarball would be However, the notes on the testing section of the documentation apply to that tarball just as well as for the rest of the subversion checkout: use for development and evaluation purposes only - no support given. You do not have permission to ask questions related to it on the coppermine support board.


Don't be afraid that there is some special magic or hidden password stuff if you want to perform a checkout: anybody can check out (i.e. download) from the SVN repository. Active Coppermine developers can additionally write their changes back from their local working copy to the repository - this is named "checking in" or "committing". Regular users (non-developers) don't need to worry about passwords - they can't write back their suggested changes to the repository. If you (as non-developer) want to propose code changes, use the forum and post your proposals.

Check out before checking in

To make sure that changes made by other developers don't get lost you (as Coppermine developer) should always perform a checkout (update) before checking in.

Committing your code

When using the Windows-driven subversion client tortoise, simply right-click on folder that represents the root folder of your local working copy and choose "commit" from the context menu to upload your changes to the repository.


The changelog is meant to be a documentation of the added features and fixes that went into the release as well as a good list of improvements. This way, we can make updating more attractive to end users, as they would have to rely on our word that the new version is better than the old one - the improvements and added features should all go into the changelog in reverse chronological order, with the oldest record at the very bottom and the newest record at the top.

This being said: all non-trivial commits performed against the subversion repository should be documented as well by a corresponding changelog record that summarizes what your commit is meant to do.

The changelog file resides within the root folder of each coppermine package and is named CHANGELOG.txt.

The changelog format is structured in a self-explanatory way, so here's just a short summary how each line is composed:


Use the international scientific notation YYYY-MM-DD to allow easy sorting

Commit type

Use a token from the list in square brackets that explains what type of commit you have performed. As of now, the following tokens exist:

Explanatory text

Text that explains your actual commit. When refering to a bug brought up on the forum, refere to the thread ID there.

Developer name

Add your name or nickname in curly braces

It's mandatory to edit the changelog (even when contributing minor fixes or features). Please try to remember updating the changelog when commiting.

Plugin authors are encouraged to maintain a changelog file for their plugin as well, at least if you plan to release your plugin publicly.

Obtaining write access

As suggested initially on this page, the subversion repository is meant as a tool for the developers to maintain their code changes. Only developers of the coppermine project who have explicitely been allowed to have subversion write access can change the files in the repository. It is not possible to assign subversion write access for particular sub-folders of the repository.
Subsequently, when you have a contribution to make (i.e. if you improve one or more files that reside in the repository or if you have created something new that belongs into the repository in your opinion), post your suggestions on the coppermine support board. If you can't post in a sub-board where your contribution belongs to in your opinion, post it in the corresponding support board - a moderator will move your posting accordingly if applicable.
Subversion write access is only being granted to Coppermine dev team members. The Coppermine project manager then needs your Unix nickname name on to assign subversion access for you.

Step by step

We will provide a short step-by-step guide how to check out the mainstream cpg1.5.x repository using the Windows-client TortoiseSVN. Please understand though that this goes unsupported; please don't ask questions about it on Coppermine's support forum.

Download the client application

Initial checkout


As you can see by looking at any coppermine source code file, there is a reference to a revision number in each file (deliberately added). This is supposed to help developers mostly, as you can clearly determine wether files are up-to-date.

Additionally, the revision numbers are being (ab)used to track files when upgrading; the versioncheck mechanism compares file revisions as well, so let's explain what the revisions are for.

Each time a developer (who has write access to the subversion repository) committs something (adding a new file to the svn counts as well as committing as deleting a file or editing the contents of a file), a the revision number of that repository counts up. Whenever a file is affected in the commit, it will "inherit" the revision count from the commit operation.

Let's assume that someone starts a new subversion repository. The revision count starts at "1". He then commits three new files to the repository (i.e. he "uploads" those files to the repository) - let's assume that those files are named "a.txt", "b.txt" and "c.txt". This upload operation makes the revision counter increase from 1 to 2. All three files now have revision "2". Then, the developer modifies file "b.txt" and commits his change (the commit will be revision 3). If you look at the files, "a.txt" and "c.txt" will have revision "2", while file "b.txt" has revision 3. Now, another developer comes into play, he edits file "a.txt" and "b.txt" and commits those changes. Revision counter goes to 4, so our files look like this: "a.txt" - rev.4, "b.txt" - rev.4, "c.txt" - rev.2.

As you can see from the example, this is a great thing to keep track of file revisions: whenever a file changes, it will get a new revision number.

This is great for the developer, but what's the benefit for regular users then? To be able to understand this, you'll have to understand how releases work: the dev team decides that it's time to release a new package, so the packager (the dev team member who is in charge of creating the package for end users) will perform a checkout from the SVN repository to make sure that his local files are up to date. Then he creates an archive and uploads that archive to the downloads section of the coppermine webspace, where the end user can get that package. In each of the files inside the package, the revision numbers still show through, but don't have an impact on the release, so you (the end user) don't need to worry about the revision numbers in the first place - after all, you the package you have downloaded has got a version number, that's all you need to know. However, development continues - developers are still fixing bugs in the repository, so the revision count of the files in the svn repository will increase. There won't be a new package release just because just one file in the repository changed - usually, several changes (=fixes) will be rolled into one when a new package is being released. Now, what's the catch? Well, between official package releases, you can still get the most recent files from the svn repository - that's recommended for users who are concerned about security, but as well if you experience an issue with your gallery and read about a fix on the bugs board that a developer has reported to be fixed in the svn. If you want to get the fix, head over to the web SVN, browse it and get the file that contains the fix. Use it as a replacement for the file on your server that was buggy. If you do that, versioncheck will report your file on the server to be newer than expected (because it actually is newer than the file that went into the released package).

Subversion file headers

In all textual Coppermine files (i.e. files with the extensions .php, .htm, .css, .js, sql, .txt, .xml) there is a subversion header present that is meant to help developers and power users to determine what version and revision number a particular file is. This can be helpfull when troubleshooting as well as in support matters. However, from a technical point of view (as far as the core functionality of your gallery is concerned), the additional subversion file headers are just for information purposes and don't server any technical purpose.
Subsequently: if you're an end user, you can savely remove the subversion file headers from files where this bothers you, e.g. if you want a clean HTML output (code-wise) of your pages you can remove the subversion file header from the HTML template file of your custom theme (themes/yourtheme/template.html).
Developers and contributors on the other hand are required to preserve the subversion file header or add it when coming up with new files that end up under version control (see "Adding files").
The idea behind the subversion file header is that it always get's updated automatically be the subversion software whenever a user with subversion write access committs a file. Think of the lines as placeholders: the subversion keywords $HeadURL$, $Revision$, $Date$ get replaced by their actual values - in this document, the equivalents are $HeadURL: $, $Revision: 8154 $, $Date: 2011-01-02 20:44:22 +0100 (So, 02 Jan 2011) $. There is no point in manually editing the content of those values - remove the information if you're an end user and it bothers you, but it won't affect your gallery in any way, so it's easier to leave the subversion file headers as they are.