On Sunday afternoon, Travis was busy examining the different version control systems (often abbreviated as VCS) to decide which one to use for his NaNoWriMo project.
That he should put his work in version control had been decided a little earlier. Travis only had to look at the numerous times during his job as a developer when he had needed to restore a part of the application logic to an older version. Also, the history of changes was helpful in how (and why) a particular piece of application logic came to be in its present form. While he was aware that Penana had the facility to create and save multiple draft versions, it lacked some of the features which a version control system provided.
Almost all version control systems, Travis knew, provided a few common functions. You could maintain different "versions" of a particular file in the system, and could display the contents of a file for a particular version. The process of adding a new version to the system was commonly referred to as a "commit" or "check-in", while a "checkout " was the term used to describe the process of fetching the contents a particular version. In addition, all systems allowed the user to enter some kind of textual comments (for example, a brief description of changes done) while checking in their changes in the system.
For text-based files, most of the version control systems maintain only the additions and deletions that are made in a particular version with respect to an earlier version. Whenever the user requests a file of a particular version, the system uses the details of these delta changes to reconstruct the required version from the original file. This method is primarily preferred as it saves storage space, while keeping a record of all the modifications. In addition, there are specialised programs, having either command line or graphical user interfaces for comparing files. The graphical comparison tools provide colour coding to visually identify additions, deletions and modifications between the versions being compared. The common colour scheme which almost all of the graphical comparison software follow is to represent additions in green, deletions in red and modifications in yellow.
The older version control systems (like Concurrent Versions System and Subversion) worked on a client-server model, whereby the server contained all the versions of the files. The client was the end user, who checked out the particular version (or tag, which is like a sort of label you could apply to multiple files of a specific version) of the files he/she was interested in. This primarily meant two things. Any user had files for only a particular version, and if the central server crashed or could not be reached due to loss of network connectivity, then you effectively lost access to the entire repository.
This was the primary problem which newer version control systems have tried to solve. They took the concept of peer-to-peer file sharing and applied it to version control. These newer systems came to be known as Distributed Version Control Systems (often referred to as DVCS) and have replaced the older version control systems almost completely. However, if required, most of them can still be configured to function using the older client-server model.
The basic concept here is similar to that of file sharing protocols like BitTorrent. There are two main types of users connected to a BitTorrent network, the users who have completely downloaded a file (called as the seeds), and there are the users who are currently in the process of downloading the same file (referred to as the peers). What happens in protocols like BitTorrent is that a peer can fetch portions of same the file from one or more seeds, thus effectively increasing download speed. Due to the decentralised nature of the protocol, the download can continue uninterrupted as long as sufficient seeds exist.
The same concept is applied in Distributed Version Control Systems like Git and Mercurial. By default, the version control system will copy (or clone, as it is often called) the entire repository to the user's machine. That means data of all the versions for all the files is downloaded from the server. This repository can then be used by others to update their repositories. Thus, in this case, the user with the most up to date copy of the repository serves as a seed, with the other users acting as peers. While approach this does increase in storage space required, it does away with the dependence on a central server. The users can continue committing their changes to the repository and keep receiving changes created by others as long as their computers are connected to each other.
All this Travis knew because he had worked with Git and Mercurial repositories during the course his career as a developer. He also knew that each of these systems had their own pros and cons. And unlike the heated debates that were common over the Internet about which DVCS was better, Travis considered most of them to be equivalent as far as functionality went. True, there would be some features that may be better implemented in one version control system, but that meant there were also others which were not. It all depended, as does in most cases, on the requirement.
But for NaNoWriMo, Travis was thinking of something different. He was thinking about using Fossil for this project.
Fossil was another Distributed Version Control System. He had come across it when reading about distributed version control systems on the Internet. And since then, he was interested by it. He used it occasionally for some of his hobby projects, and it had worked without any major problems.
The main reason Travis was thinking about Fossil was due to the some of the motivations behind designing the system. Like Git and Mercurial, which had started out as systems for managing the source code of the Linux kernel, Fossil had begun as a system for managing the source code for the popular SQLite database engine. And this core problem which these systems set out to solve had influenced their design in more ways than one. For instance, the Linux Kernel has a large number of volunteers and software organisations besides Linus Torvalds who contribute to the source code. These contributors are from different parts of the world, and at times may never meet each other, or know what modifications other contributors are making to the same file. SQLite, on the other hand, is built by a team of three developers, who regularly get together to discuss about the project. This is one of the reasons Git allows users to create local changes which are not visible to other users unless explicitly pushed to the main repository (often referred to as private branches) and Fossil, by default, makes all changes visible to all the team members. In short, Fossil is ideal for those projects where the team size is small, while Git, Mercurial and others were better suited for bigger projects involving large teams, where there are a lot of things going on at the same time. This was also the opinion of many who had used Fossil (Travis included).
After thinking along these lines for some time, Travis finally decided to go ahead and use Fossil to save his work. He opened the file explorer on his computer and navigated to the folder where he had checked out the Fossil source code. As can be expected, the Fossil source code is hosted in a Fossil repository. Using the right-click context menu, he opened a terminal window. Even though he was running Linux, Travis sometimes preferred to use the 'Open in Terminal' feature provided by the file manager as it opened the terminal with the folder displayed in the file manager as the current working directory. This helped to avoid typing the commands to navigate to the folder in the terminal window. He then updated the code to the latest version by issuing the 'update' command. Then in the terminal window, he navigated to a sub-folder named 'build'. Travis, like most developers, followed this practice of building the programs in a separate sub-folder in order to keep all the files generated during the compilation process separate from the source files.
The folder already contained files from an earlier version he had built some months ago. He first cleaned the files created by the earlier compilation by issuing the command 'make clean'. Then he ran the configure script and finally, once he was satisfied that the build environment was properly configured, he issued the 'make' command to start the compilation process. The terminal window was filled with many status messages as compiler processed the different source files and ultimately generated the Fossil executable. Then he issued the 'make install' command (as root user), to finally install the newly built Fossil binary in his system.
After the installation was done, he started with the creation for a new repository for his NaNoWriMo story. As it was some time since he had last used Fossil, he opened the Fossil User Manual for reference. First he created the SQLite database that he store his repository using the 'open' command, in a separate folder on his hard disk where he stored all Fossil repositories. Next, in the folder where he kept his hobby projects, he created a new folder for storing all the files related to his NaNoWriMo story.
Now he had to connect this folder to the repository database he had created earlier. This he did using the 'open' command. Then he copied the analysis of the genres, plot outline, and his notes (all of which he had already replicated on his computer by writing the points jotted down on the notepad in a spreadsheet or text document, as the case may be) into this folder. As these files were new, he had to first add them to the repository using the 'add' command. This was followed by an initial commit of the newly added files.
Now that all the preparatory activities were done, Travis ready to move on to the next step of beginning to write his story. He decided to stick to his earlier plan of reviewing the plot outline again in the coming week and update it on the NaNoWriMo website by the weekend.
As Travis shut down his computer, he realised that he was feeling a little sleepy (it was a Sunday afternoon, after all). So he decided that a short nap was in order. He set the alarm for an hour later and a few minutes later, he was asleep on his bed, snoring softly.
ns 15.158.61.20da2
