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.
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.
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.
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.
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.
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.
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.
The term "checkout" actually stands for "download the files from the repository to your local (working) copy on your client".
svn co svn://svn.code.sf.net/p/coppermine/code/ coppermine
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/
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.
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.
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.
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), 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).