Version Control Software
Version Control Software
A number of software titles exist for handling version control. In this short section, you'll explore three of them, examine the pros and cons, and see how they implement the common functionality and principles of version control.
There isn't space in this appendix to go into much detail regarding the setup, installation, and maintenance of each one. Plenty of documentation exists on the Web detailing the ins and outs of each. But this section should at least allow you to make an informed choice as to which version control platform is most appropriate for your project.
Microsoft Visual SourceSafe
SourceSafe has been around for a long time and now comes bundled with copies of Visual Studio .NET. It may seem an unusual package to use in a PHP environment, but it is definitely worth a look.
Although not free, its Windows-based client is particularly pleasant and easy to use. Although PHP development folk never shy away from a challenge, there is little point expending energy on figuring out how to use your version control client when you could be using it to figure out a neat way to approach an algorithm or object model. SourceSafe is so straightforward to use, you can do just that. Figure A-2 shows a typical view from SourceSafe. As you no doubt can see, it appears to be very similar to Windows Explorer and hence is very easy to pick up.
Figure A-2
On the flip side, SourceSafe uses shared disk space rather than a proper client server protocol for its repository. This has the usual problems associated with shared Access databases, and accordingly can be horrifyingly slow to use on larger files with many revisions. There are also a few irritating facets that boil largely down to differences between Windows and UNIX, such as filename case-sensitivity.
SourceSafe uses solely Exclusive Versioning that is, when a file is checked out, nobody else may check it out. As with many packages that use Exclusive Versioning, this is enforced using the read-only attribute of the local copy of the file. Because this is a Windows-based client, developers will almost certainly be checking out to a network drive. Strictly speaking, this is slightly inefficient. The workstation is acting as a conduit for the downloaded data rather unnecessarily.
SourceSafe stores its database in a completely arbitrary format, so you can't use its repository storage area as a form of automatic staging server. There is a fairly comprehensive command-line syntax, however, which you could use to build automated scripts for downloading latest versions for a staging server. Such a script, of course, would need to run from a Windows environment because there is no UNIX client of any description.
Well worth a look, but keep in mind that the licensing costs may be prohibitive for small projects. You need to pay only for copies of SourceSafe, however. Because it relies on shared disk space, there is no server as such, and you could even use a network drive presented by Samba running on Linux.
CVS
CVS stands for Concurrent Versioning System and, as the name suggests, is one of the better-known examples of a version control platform that implements Concurrent Versioning for developer check-outs. CVS has the great advantage of being released under the GNU Public License, which means that it is essentially free to download and use.
It stores its repository in a folder largely mirroring the real directory structure of the project in question, and uses small tag lines in files, hidden files in directories, and minor filename concatenations to store auxiliary data beyond the latest versions of the files themselves. This is in stark contrast to the manner in which SourceSafe stores its files.
CVS clients can connect to CVS in one of two ways: by simply looking at the repository directly (if it resides on the local machine) or by connecting using the pserver protocol. It would, in theory, be possible to share a network drive (`a la SourceSafe) to allow the former connection method, but using the pserver protocol is by far the best way to implement CVS over a client/server environment.
CVS is generally run underUNIX, and typically on the same machine on which the local copies of the files are to live. In the previous topology example, CVS was run by each user via a shell connection to the development server. For the more UNIX-savvy, this is probably the preferred route. For the not-so UNIX-savvy, a SourceSafe-like Windows client called WinCVS exists that replicates most of the UNIX client's own functionality. Figure A-3 shows a typical view from the Windows client. As you can see, the WinCVS client shares an interface remarkably similar to that of SourceSafe.
Figure A-3
Resolving conflicts in CVS is usually relatively straightforward. CVS takes the merger as far as it possibly can and then presents the user with a new version, annotated to demonstrate the conflict. The user then modifies this new version to resolve the conflict, saves it, and recommits it. CVS then stores this as the latest version. Difficulties do, of course, arise when the conflict is more serious.
CVS can be a good choice, but its Concurrent Versioning may not be to everybody's taste, for the reasons outlined earlier in this appendix. Consider carefully whether this is appropriate for the project, and if not, whether its presence could encourage poor working practices among your developers.
RCS
The ancestor of and indeed still the underlying basis of CVS, RCS is a nonconcurrent Exclusive Versioning platform that has been around going on twenty-five years now. Concerning projects for which SourceSafe is too expensive, too slow, or too cumbersome, it provides an attractive alternative, although it is arguably less well supported than CVS these days.
In addition, many useful features of CVS are not related to Concurrent Versioning, such as the grouping of files into a single collection (treated as one object, in effect) and automatic determination of file states. In effect, RCS is a more raw version of CVS. This may suit some developers, but for many it will prove just a little too fussy to live with on a daily basis.
