Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2003
Pages: 182
Pages: 182
There's a lot more to version control than there is space to cover it in this short appendix. As with so much in PHP, the topic can constitute a book in its own right. There are a few interesting techniques, however, that you may wish to employ in your chosen version control environment.
Branching involves the divergence of a single project into two parallel projects. This is an immensely useful technique for code reuse.
Say that you are developing two content-management systems for two different clients, systems that are virtually identical in functionality the only differences are minor or aesthetic in nature. Obviously, you will wish to reuse code from one in the other, but doing so has a pitfall. If you make a major change in the first, you will want that change to propagate to your second project. Conversely, any changes you make in the second project, you will probably not wish to propagate upward to your first project, because these will be customizations.
Branching is the solution. By branching the first project to form a second, your version control software will automatically propagate any changes made to the first project into the second project as and when they happen, while retaining changes made in the second project as customizations unique to that second project.
Branching can also be used to maintain two different directions for a project. For example, you may wish to have one set of developers work on a maintenance release of your product while another set works on the next big major release. Branching allows you to take a snapshot of your product in time and then branch off into two distinct development paths, safe in the knowledge that any major changes in the prebranch product will be propagated into both paths.
Not to be confused with the tags CVS places in individual files as mnemonics for its own use, tagging involves applying an arbitrary attribute to a given version of each file to create release versions.
For example, you may wish to create a beta version of your project. This will involve more or less every file in your project being packaged together, but you may wish to use different versions of each file version 1.3 of this file, 1.5 of that file, and so on. By tagging the right version of each file, you can then easily tell your version control software to deliver a particular version on demand. Individual developers can move tags as and when they feel confident, so that at any given time when requesting a particular version be it beta, release candidate 1, or whatever, you can be sure that you will be getting the latest stable version.
One often overlooked facility of all version control systems is the application of comments at check in. When checking in a file, the developer will be asked to supply a comment. It is a good idea to ensure that your developers do take advantage of this facility and supply a brief description, even if it is something as simple as "fixed bug 21301.'' When showing the history of a particular file, this information can be immensely useful.
Care should always be taken when adding binary files, such as images, to a repository,. Although it is generally a good idea to keep the entire project in one place, many version control packages are immensely inefficient at handling binary files and can slow to a crawl when faced with a few dozen JPEGs.
Consider whether there is a third way. For example, consider all those .GIF files containing page titles. Could they be replaced by a single PHP script, which uses imagefttext to render a caption as and when required? Such an "outside the box'' approach can be of critical importance, because binary files represent one of a small number examples of when version control can prove inappropriate or cumbersome.