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

Table of Contents

Git

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.

Git is a version control system developed in 2005 by Linus Torvalds 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 clone the Git 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 Git access. Primary target audience for this page are Coppermine developers though.

Caveats

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 Git access as well as development versions go completely, utterly unsupported.

What is Git?

Git is a revision control system which allows computer software to be developed in an incremental and controlled fashion by a distributed group of programmers. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows. Git was created by Linux Torvalds.

Git 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 Git is particularly common on projects with multiple developers, since Git ensures changes made by one developer are not accidentally removed when another developer posts their changes to the source tree.

Where is the Git repository hosted?

Setting up and maintaining a Git repository is something that you can't accomplish on a "regular" webserver (on shared webhosting). That's why the Coppermine team has decided to host the Git repository at github.com, 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 GitHub

For those who don't want to download and install a full Git client software you can use "GitHub's web-driven interface to browse the structure of the Git repository. This interface gives you the opportunity to download or view individual files.

Repository structure

Coppermine core files

The most recent version of the Coppermine package for cpg1.6.x resides in the repository at https://github.com/coppermine-gallery/cpg1.6.x.git.

Plugins

The most recent version of the plugins for cpg1.6.x that are being maintained in the Git repository (not all plugins are under version management) resides in the repository at https://github.com/coppermine-gallery/cpg1.6.x-plugins.git.

// TODO: continue here to reflect switch from Subversion on sourceforge.net to Git at github.com //

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 svn://svn.code.sf.net/p/coppermine/code/ coppermine

Checking out a particular Package

Users interested in the mainstream development should check out the sub-folders of the "trunk"-folder. For cpg1.5.x, you should check out https://svn.code.sf.net/p/coppermine/code/trunk/cpg1.5.x/

Checking out a particular file

If you're interested 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 web SVN interface provided by sourceforge.net. 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 subversion 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.

Developers-only

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.

Changelog

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:

Date

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 sourceforge.net 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

Revisions

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), 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 serve 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 helpful 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 gets updated automatically by the subversion software whenever a user with subversion write access commits a file. Think of the lines as placeholders: the subversion keywords $HeadURL$, $Date$ get replaced by their actual values - in this document, the equivalents are $HeadURL$, $Date$. 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.