What is Revision Control?
Software source code revision control tools are designed to store multiple revisions of a software's source code. Each change to the software's code is stored along with some metadata about that revision of the code, including who made the change and when. Usually, a short message is also associated with each revision.
Why use Revision Control?
Revision control is useful for many reasons - it documents the change history of the software, it allows software developers to go back in time to trace when bugs were introduced, and it allows developers a certain degree of freedom to experiment - if it doesn't work out, they can always roll back to a previous version of the software. Revision control tools, along with bug tracking tools, help to ensure that proposed changes to a piece of software don't get lost, because it's easy to tell whether or not a particular change is in the code or not (and if it is, when the change was made, and by whom). Revision control tools, especially distributed revision control tools, also help software developers communicate changes in the software with one another.
Current Practice
Internally, we have been using Mercurial to track the OpenVista Server codebase. At the time we started using Mercurial, we chose it for the combination of its speed, relative familiarity/ease of use (compared to Git), and extensibility (Mercurial is mostly written in Python). Our approach is fairly crude - we have an instance of OpenVista Server running on GT.M, and whenever we want to do a commit, we stop all the mumps processes, run down the database files, and commit everything. Whenever we install a KIDS build, we also add the KIDS build to the repository and commit it alongside the globals and routines.
This gets us very basic revision control, but it's far from ideal. Probably the biggest drawback is speed - Mercurial takes on the order of ten minutes to do a commit because the database is over 400MB. Mercurial also needs to search through 24,000+ routines to see if any of them have changed. Fortunately, Mercurial does a pretty good job of figuring out which database regions have changed and records reasonably small deltas, i.e., each commit does not add 400+ MB to the Mercurial repository. Another drawback is compatibility - since we're committing actual GT.M database files, all of our developers need to be using the same version of GT.M (note that we do not commit compiled object files). Also, "hg diff" is unable to display the differences between one revision of the globals and another because it's just a gigantic binary blob.
Future Direction
As we work on opening up the OpenVista Server development process to the community, we would like to address some of these shortcomings. One of the easiest things to do is to store the globals in a more universal format. Committing globals in ZWRITE format (see the mupip documentation) would allow us to remain GT.M-version agnostic (actually, MUMPS-database agnostic) while providing the additional benefit of meaningful "hg diff" output (thanks to Bhaskar for this suggestion). Of course, "hg diff" would show global-level differences and not FileMan-level or application-level differences, but there are utilities in MUMPS (such as the % routine) that can perform such comparisons. Of course, the disadvantage to exporting the globals before committing them is that the commit process will take longer because it takes some time to export globals in ZWR format. The checkout process will also take longer because it takes time to import the globals.
Another possible enhancement is to switch revision control systems. Since we're already using Bazaar for OpenVista CIS development, it may make sense to switch to Bazaar for OpenVista Server, too. At the time we started using Mercurial, Bazaar was not fast enough for us to consider it, but Bazaar continues to be developed and improved at a remarkable pace. In particular, Bazaar stores its data differently now, and Bazaar's latest repository format may actually provide some performance benefits over Mercurial when checking out routines (24,000 small text files). We hope to post some concrete benchmarks showing the performance of various tools when working with OpenVista in the near future.
Finally, we want to build some tools around viewing code repositories directly into the Medsphere.org site - see VistA code repositories at Medsphere.org for a more detailed discussion on that topic.
