Back when Lotus Notes was still wearing short pants, let’s say before about 1995 or 1996, the issue of version control would never have come up in conversation around the Notes development team’s water cooler. In fact, back then, most Notes developers probably wouldn’t have even known what version control, revision control, source code control or whatever you want to call it, even was.
Many people who found themselves building and maintaining Lotus Notes applications had not come from a traditional software engineering background, having started out as a “power user” and developed their skills in sync with the evolution of Notes as an application platform. Admittedly, I went to school for computer science a long time ago (class of 1984!) but even back then, it was drilled into me to use SCCS and Make for version control and build management.
It always struck me as a great irony that Lotus Notes - an application (platform) that was based on collaboration - never included any features that would facilitate collaboration amongst Notes developers. That wasn’t necessarily surprising in the early days of Notes - the programming environment was so straightforward that it would be pretty unusual to have more than one developer working on the same application at the same time.
But as time went on, developers got more ambitious and the types of applications being developed on the Lotus Notes platform become more complex. By the mid-to-late 90s, there were some pretty sophisticated salesforce automation and customer service applications being delivered on Lotus Notes.
As you can imagine, these apps were being built by teams of people, and the task of keeping track of who was working on what was becoming more problematic. And, as the complexity of the applications increased, so it became more important to keep track of which version of an application was in production, even if the whole app had been developed by the same person. And so it was that Teamstudio CIAO!, our version control system for IBM Notes and Domino, was born.
But I’m getting ahead of myself. For the benefit of the uninitiated, let me explain the types of version control system (VCS) and why it’s important to understand the differences between them. To all intents and purposes, there are two types of VCS: centralized and distributed.
Centralized Version Control
A centralized version control system works on a client-server model. There is a single, (centralized) master copy of the code base, and pieces of the code that are being worked on are typically locked, (or “checked out”) so that only one developer is allowed to work on that part of the code at any one time. Access to the code base and the locking is controlled by the server. When the developer checks their code back in, the lock is released so it’s available for others to check out.
Of course, an important part of any VCS is the ability to keep track of changes that are made to the code elements, and so when an element is checked in, a new version of that piece is created and logged. When everyone has finished working on their different pieces and it’s time to make a new release, a new version of the application is created, which usually just means logging the version numbers of all the individual parts that go together to make that version of the application.
Probably the best known examples of centralized VCS systems are CVS and Subversion, both of which are open source, although there have been many commercial examples (including IBM’s Rational ClearCase).
Teamstudio CIAO! also falls into this category, but I’ll come back to that later.
Distributed Version Control
More recently, there’s been a trend (or some might call it a revolution) toward distributed version control systems. These systems work on a peer-to-peer model: the code base is distributed amongst the individual developers’ computers. In fact, the entire history of the code is mirrored on each system.
There is still a master copy of the code base, but it’s kept on a client machine rather than a server. There is no locking of parts of the code; developers make changes in their local copy and then, once they’re ready to integrate their changes into the master copy, they issue a request to the owner of the master copy to merge their changes into the master copy.
With a DVCS, the emphasis switches from versions to changes, and so a new version of the code is simply a combination of a number of different sets of changes. That’s quite a fundamental change in the way many developers work, which is why DVCS’s are sometimes considered harder to understand than centralized systems.
The best known examples of distributed VCS’s are Git and Mercurial, both of which are open source.
Pros and Cons
The key difference between centralized and distributed VCS’s, in my opinion, revolves around the fact that there is no locking of elements in a distributed system. So every new set of changes that a developer makes is essentially like a new branch of the code, that needs to be merged back into the master repository. In the distributed model, it’s possible for two developers to be working on the same source file at the same time.
That one fundamental difference means that:
Performance of distributed systems is better, because there is no waiting for locks to happen across potentially slow network connections. Also, the complete code base is already on your local system.
Branching and merging is much easier to achieve in a distributed system, largely because it’s built in to the way the system works.
With a distributed system, you don’t need to be connected to the network all the time.
For these reasons, many people have become DVCS fans and believe that Git and Mercurial are the answer to any VCS question. However, centralized systems like Subversion do have some benefits too:
Centralized systems are typically easier to understand.
Access control is easier, since everything is controlled from one place (the server).
Unless you want to, you don’t have to merge different versions of the same code, which can be tricky.
VCS’s for Notes and Domino
So what about us IBM Notes and Domino developers? What’s the best version control system for us to use? To answer that question, there’s another aspect to this that you need to consider.
Pretty much every VCS system that we’ve talked about here works on the assumption that the individual pieces of code that are being manipulated map neatly onto text-based files, i.e. source code. As you probably know, that doesn’t apply to your typical Lotus Notes application. The individual design elements (forms, views, script libraries, etc) in a Notes database design are usually all contained within a single file (NSF or NTF).
That gives you two problems if you want to use a file based distributed VCS like Git or Mercurial. First, the Notes design elements can’t be divvied up and distributed out to individual developers’ workstations in a natural way. And second, even if they could, merging them back into the master copy of the database design would be a nightmare, without some specialized tools.
Theoretically, you could export your Notes design elements to DXL and use a mainstream VCS to manage the text files that it produces. However, we are not aware of anyone who has been able to create a workflow that works in practice using that method. Which is why we still consider that, if you are building or maintaining classic Notes applications, Teamstudio CIAO! is the way to go.
CIAO! integrates into Domino Designer and allows you to lock, or check out, individual Notes design elements. When you’re done with your changes, you can check those elements back in again, releasing the lock. CIAO! builds a complete history of all the changes to every single element, allowing you to revert back to previous versions. You can also stamp all elements with a revision number when it comes time to make a new release of the application.
In summary, if you’re building applications using traditional text source files, for example using JavaScript and Node.js to access Domino data, then a distributed VCS like Git is probably the best choice. But if your applications are classic Notes apps, with forms, views, and script libraries, then you should check out Teamstudio CIAO! (See what I did there?)
To learn more about CIAO!, arrange a demo or just chat about any aspect of version control for IBM Lotus Notes and Domino, click below. We’re always happy to chat!
POSTSCRIPT: Ever wondered why CIAO! is called CIAO!? It stands for “Check In And Out.” Someone who shall remain nameless came up with that early on the development of the project, and for some reason it stuck. And yes, it’s pronounced “chow.”