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

# Subversion

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.

## 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.

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

- Free SVN client for Windows: TortoiseSVN
- Official SVN client for Linux and BSD: subversion.tigris.org
- Recommended GUI client for Linux: RapidSVN (available as a pre-made package for many Linux distributions)

## Repository structure

The coppermine SVN root resides in `https://coppermine.svn.sourceforge.net/svnroot/coppermine`
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.

## 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 https://coppermine.svn.sourceforge.net/svnroot/coppermine 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 `https://coppermine.svn.sourceforge.net/svnroot/coppermine/trunk/cpg1.5.x/`

### 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 sourceforge.net. Just navigate to the file you want and use the download link there.

## 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 downloads section: 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.

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 development version. 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 http://coppermine.svn.sourceforge.net/viewvc/coppermine/trunk/cpg1.5.x.tar.gz?view=tar. 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.

## 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:
  - [A] = Added new feature
  - [B] = Bugfix (fix something that wasn't working as expected)
  - [C] = Cosmetical fix (layout, typo etc.)
  - [D] = Documentation improvements
  - [M] = Maintenance works
  - [O] = Optimization of code
  - [S] = Security fix (issues that are related to security)

- #### 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.

## 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

- Download the most recent stable version of the TortoiseSVN.
- After the download has finished, start the install by double-clicking the installer you just downloaded
- Follow the steps of the installer
- Reboot your PC once the installer has been run successfully

### Initial checkout

- After the reboot, create a folder on your PC that will later contain your local copy. You will need approximately 25 MB of hard disk space. The location of the folder doesn't matter. In this example, we will create it within c:\my_svn_checkouts\, naming the folder `cpg1.5.x`. Subsequently, we will have an empty folder c:\my_svn_checkouts\cpg1.5.x\
- Right-click on the newly created folder
- From the context menu, choose `SVN Checkout...`
- In the field "URL of the repository", enter the URL of the folder you want to check out. For the mainstream cpg1.5.x-folder, enter `https://coppermine.svn.sourceforge.net/svnroot/coppermine/trunk/cpg1.5.x`
- Leave all other settings as they are (`Only check out the top folder` = off; `Omit externals` = off; `Revision` = `HEAD revision`)
- Click "OK"
- A dialog will pop up that shows the progress of the initial check out. Depending on your connection speed, this will take some time - during the initial check out, all files within the repository are being downloaded.
  As long as the download continues, the OK button will be greyed out (you could cancel at any time though). Once the checkout is finished, the OK button will get clickable.
- Now the full source code should reside as a working copy on your hard drive. You can now just go ahead and upload all of the files to your testbed or even set up your testbed up to just use the folder you checked out to. If you're going to upload the files to your testbed, you might want to get rid of all the extra subversion files first though (they won't hurt, but there is a lot of those small subversion files that will just take longer to transfer to your testbed using FTP). To get rid of the surplus subversion files (i.e. the files and folders that are used by the sbuversion client to keep track of changes), just copy the entire folder where you have checked out to to a temporary folder, then perform a search for files/folders named "`.svn`" and then delete all those files (i.e. the files that turn up as a search result) from the temporary folder. The files that remain will be the actual coppermine source code without the surplus SVN files. In fact, you can use the files and perform a regular install as if it was an actual coppermine package, so in fact the install instructions from this documentation apply.

## 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 subversipon 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).