If you ever worked on a free software project or if you have ever worked as a developer, you probably know that managing source code, patches, and software release cycles is not the easiest task to perform. Things get even worse if lots of people are working on the same project: more code to manage, more people to coordinate, more patches to integrate and mainstream. Even if you don’t write software or have never worked on such projects, I’m sure that as an addicted computer user sometimes you felt like “hey, why didn’t I make a backup of that document”, or “hell… I liked it better before” or “wow… why was that change introduced? I can’t remember it…”. In this article, I won’t talk about the importance of backups, which should already be clear in every reader’s mind, but I will introduce a new and very powerful system useful for managing source trees, tracking down changes, and allowing many people or groups to work together or independently on the same projects: TLA, often referred as GNU Arch, a new generation Version Control System (VCS).

Version Control Systems and your happiness

If you don’t know about VCS’s or SCM’s (Software Configuration Managers), just close your eyes (maybe at the end of the paragraph) and start imaging a big software project: lots of developers, lots of source files, roadmaps to inspect closely, bugs to find and fix, patches to be released while new features are being introduced, developed and tested. And yes, all these things being done by different people, for different reasons as time goes on.

As soon as a project starts to grow and spread among your customers or users, it becomes very important to have the ability to track:

• When and why a particular change was introduced?
• Which version of the software each customer/user has installed?
• Which changes were introduced in each version?
• Who it was that actually introduced a given change (often, a given bug)?
• Where a version of the software, which is still in use and which needs a minor change, can be found?

This is where Version Control Systems come to rescue. The purpose of a VCS is to prevent a given project, whether it be a software project or anything else that can be saved as a tree of files on your hard disk, from becoming a nightmare. Once in use, it will take care of:

• Remembering which files a project or a particular version of your project is made of
• Remembering changes that made to any file, allowing you to “undo” those changes and to know who introduced them and why
• Conflicts – preventing different people introducing “incompatible” changes to the same files without knowing
• Introducing automatisms into your software release cycles, by providing “hooks”
• Allowing you to continuously develop two or more versions of a project (often called branches), easing the task of exchanging and sharing code among them
• Easing the task of integrating changes (patches) provided by third parties

Generally speaking, a VCS could be considered some sort of oracle which knows everything about each and every file of your project, which you can ask questions or delegate tasks to (like, “please, apply this patch to the whole project… or please, show me that file as it was 20 days ago”). Once you start using VCS’s you will become addicted, and will start using them for everything, even for simple documents or articles (like the article you are reading, and no, I’m not one of the most addicted).

A VCS could be considered some sort of oracle which knows everything about each and every file of your project

TLA as your Version Control System

By now, you should be wondering why I felt such a strong need to talk about TLA in this article (no, the “Free Software Magazine” editor didn’t force me, and no, the upstream authors didn’t pay me), when so many VCS’s are available on the internet.

First of all, TLA is one of the few free (as in free speech) VCS’s available that comes with a decentralized development model in mind: it supports multiple archives, possibly managed by different people, created for the same project. It also provides support for archives to import/export patches and pieces of code from each other, without loosing track of who made them and where they came from.

Second, TLA is very powerful in what it does, still being extremely simple, both in its usage and in the way it works. For example:

• An archive is a simple hierarchy of directories, each one containing a .tar.gz with either the sources of the project or some sort of “diff” file and a couple of text files used internally by TLA (usually, the log entry and the checksums of the files). Other VCS’s use Berkeley DB databases, SQL backends, proprietary database formats, etc.
• It doesn’t need a dedicated server. TLA can store, access and write archives using standard protocols like SFTP, FTP or HTTP (using WebDAV for write support).
• TLA supports symlinks, renaming both directories and files, keeps track of privileges and file system permissions
• It supports GPG signed archives and operations, and more.

Choosing the right VCS is a matter of looking at the development model being used. Obviously, TLA doesn’t fit well with every development model. While there are limits that only TLA is able to overcome and models that only TLA fits, there are other VCS’s able to overcome some of TLA limits and that fit better with other development models. Be careful before taking any decision in any direction.

Choosing the right VCS is a matter of looking at the development model being used

Starting up with TLA

Without going into the details of the various commands, details you can find in any of the many TLA tutorials, let’s see what you need to do and how things work with TLA.

The first time you install TLA, you will need:

• To introduce yourself to TLA, by stating your name, email address, and the address that will be used by TLA to generate the changelogs
• To create your own archive or repository, a place where TLA will store all of your projects, or trees, and all of its own data
• To import one of your projects into TLA, and start working on it