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.
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.
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.
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.
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.
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 https://coppermine.svn.sourceforge.net/svnroot/coppermine/branches/cpg1.5.x/plugins, i.e. it is available via web SVN over http://coppermine.svn.sourceforge.net/viewvc/coppermine/branches/cpg1.5.x/plugins/.
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 https://coppermine.svn.sourceforge.net/svnroot/coppermine/branches/cpg1.5.x/plugins/coffee_maker, 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.
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 |
The term "checkout" actually stands for "download the files from the repository to your local (working) copy on your client".
svn co https://coppermine.svn.sourceforge.net/svnroot/coppermine coppermine
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/
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.
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.
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.
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 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.
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.
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.
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:
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.
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.
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 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).