Alpha Anywhere and Source Control
Article authored by Jerry Brightbill - Alpha Anywhere Development Team
All software projects require some management.
Simple projects may only need solutions to back up the various structures to prevent data loss or recover an earlier version of some files. But as projects become more complex, there may be a need to support multiple developers working on the same project or a need to maintain a history of changes to be able to easily recover older versions of files.
The simplest solution is some form of drop box that contains the latest versions of various files coupled with a backup program that regularly stores a snapshot of the files at any given time. However, a drop box system has some problems as it is difficult for one developer to know if someone else has modified a file when they add a revision to the storage, and finding the edit history of a single file is very difficult.
That is where source control systems become important tools for project development.
Source Control Systems
Source controls systems are fairly complex systems. They are far more than common repositories. Wikipedia has a decent entry on revision control, with is just another name for source control.
http://en.wikipedia.org/wiki/Revision_control
There are many different source controls systems, and each has strengths and challenges. This article won’t go into the details of each system or recommend any particular system, but a rather good comparison of common systems can be found at this link
http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/
They require a server (for the master repository) and client application on the local machine. They all use some type of indexing and check out system to compare the local or working copy with the master copy. A local user "checks out" a file, makes changes and "commits" the changes. The system has to determine if the master changed between the time it was checked out and committed. Some primitive systems may lock the master when anyone checks out a copy, similar to checking out a book from a library, but that prevents multiple users from working on the same code at the same time.
All common systems provide some method to resolve conflicts and maintain a history to be able to roll back to earlier code. They typically include various security methods including limited user rights such as the ability to check out files from the system, but not commit changes. This is a nice feature when working with client systems where a check out only client system can be used to update a system with new revisions and changes though a source control client.
In some instances, source controls systems are used by individual developers just to maintain a revision history and be able to roll back changes and also document every change made as the system is developed.
Most multi-developer shops find source control almost mandatory and usually pick a solution and stick with it. With such a range of solutions, we can't make a recommendation as typically a development group will use whatever system or method they either already have in place or feel most comfortable using.
Source controls systems may have a significant learning curve, but many are free, such as CVS. The earliest systems were command line driven and command line can still be used for almost all systems, but there are nice GUI products such as the Tortoise products that made working in the systems easier. The challenge is usually in the setup of the source control server system. Since most solutions are well developed with large user bases and are free, it would make little sense to develop a special system within a software product.
Using Source Control with Alpha Anywhere
Alpha Anywhere has a number of features to make working with source controls systems easier. This includes moving reports to dedicated files in web projects, and using a file system for the workspace library.
Alpha Anywhere stores most design elements in individual files, such as components, style sheets, images, and web pages. Source control systems can easily manage each file and store a history of changes.
The only areas were source control doesn't work very well is merging or comparing changes in components as they are saved as binary, and changes made to the workspace data dictionary such as special scripts or functions that may be published as an AEX file.
In the case of components, comments added to the source control commits about changes made are very useful. If the comments are clear, multiple developers should be able to track the changes even if they can't directly compare the source code.
In a web app, typically very little is saved in the workspace data dictionary if the web components use AlphaDAO as a data source. Reports, letters and labels for SQL sources originally were stored in the dictionary, but we now allow building those directly in web projects, so they can be managed by source control very easily.
The workspace data dictionary library can also be converted to a file system if it uses scripts and functions that may be published in an AEX. In a file system, every layout, script and function is saved in individual files in special library folders. This makes working with source control much easier as a single function exists in a single file and can be updated without impacting any other code.
Conclusion
Source controls systems can be important programs in a developer’s arsenal of tools. Not only will they support multiple developers working on a project, but they maintain a history of changes which document how the project evolved. At Alpha Software we continue to look as methods to make using source control easier.
Comment