Arch for CVS Users

CVS users, don't let the next-generation version control system scare you. The basic functionality in Arch can be just as simple as CVS. Nick covers the basic commands you need to get started

It has been known for some time now that CVS, the workhorse revision control system for the Free Software community, is at the end of its operational lifespan. Projects such as subversion have worked hard to fix some of the more prominent flaws in CVS's design (no atomic commits, no metadata versioning), but recently a new class of source control system has arrived, championed by GNU arch.

Arch is, at its heart, a distributed system. There is no special server process, and each developer's machine can serve as an arch repository. The result is that advanced use of arch can require more work on the client side.

These advanced features often confuse CVS users who wish to upgrade to arch. Compound this with the fact that many of the documents written for arch were originally closer to API-level descriptions than actual user tutorials, and you end up with a widespread conception that arch is somehow difficult to use.

If you are a CVS user who is looking to get into arch, here's some good news: arch can be just as straightforward as CVS if you're just getting started. Many of the commands you see in the official arch documentation are not needed for basic use.

Anonymous Checkout

tla register-archive http://www.lnx-bbc.org/arch
tla get lnx-bbc-devel@zork.net--gar/lnx-bbc--stable

The above two commands are all you need in order to anonymously check out the stable branch of the LNX-BBC project's GAR tree. The first command causes arch to look at http://www.lnx-bbc.org/arch and determine that there is a repository there (in our case, the one called lnx-bbc-devel@zork.net--gar). You can think of it as somewhat analogous to a "cvs login", in that it creates a little bookkeeping file for the repository. No actual server login takes place, however.

The second command grabs the stable branch of the lnx-bbc project from that repository. It is almost exactly analogous to a "cvs checkout" (often shortened to "cvs co").

As the project progresses, updates will be pushed to the repository. In CVS, one would issue a "cvs up" or "cvs update" periodically to ensure that the local copy of the tree matches the current state of the checked-out branch. Well, in arch you simply issue:


tla update

and the result is the same. Arch will temporarily "tla undo" local changes before applying the repository's diffs, and will "tla redo" them afterward.

Note that in CVS, conflicts between a repository's changes and local changes are reflected inline, with dividers made of greater-than and less-than symbols. Arch prefers to use the standard patch technique of creating ".orig" and ".rej" files, so that it's much easier to track down conflicts without resorting to "grep".

Generating a Patch

In cvs, one typically executes "cvs diff -u" to generate a patch file. This patch can then be mailed to upstream authors for possible inclusion. In arch this is as simple as running:


tla what-changed --diffs

Although this is not exactly ideal. Arch stores a lot of information on which files moved where, permissions changes, and changes to binary files that cannot be stored easily in diff format. If you wish to be kind to upstream developers, you'll create a changeset, like so:


tla changes -o ,,my-illustrious-changes

This will create a directory called ",,my-illustrious-changes/" (files beginning with two commas are ignored by arch for most tasks) which you can tar up and mail off.

Shared Access to a Remote Repository

Since arch does not have a dedicated server process, all remote access is through network filesystems (in fact, even anonymous HTTP checkouts use WebDAV for access). This means that commit access to an arch repository is done through the SFTP subsystem of OpenSSH (or, if you insist, an ordinary FTP server).

Thus, for the archive listed above, I instead registered the archive URL as "sftp://nick@arch.lnx-bbc.org/var/www/arch", which points to a directory that has the sgid bit set and all directories are owned by the lnx-bbc developers' group. In order to make this work, we had to use a special wrapper for the SFTP server that would set group write permissions by default.

Thus, our /usr/local/lib/sftp-wrapper file reads:


#!/bin/sh
umask 002
exec /usr/lib/sftp-server $@

and our sshd.conf has the following line:


Subsystem       sftp    /usr/local/lib/sftp-wrapper

After restarting sshd, its time to make a shared archive.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Arch for CVS Users

Anonymous's picture

in fact, even anonymous HTTP checkouts use WebDAV for access

In fact it can just use plain HTTP aswell, so you can easily host archives on any webserver you have ssh access to (or ftp, but you don't want that...).

symbolic links

Anonymous's picture

much more import is, does it support symbolic links. Because CVS does not, it is still a no go for my projects (and yes I know there are patches and scripts, but they are all quite ugly)

Re: symbolic links

Anonymous's picture

Yes, tla/arch does support symbolic links.

Arch integration with emacs and IDEs?

Anonymous's picture

So, does arch work with emacs and other IDEs in a way that is comperable to the way that cvs does?

Re: Arch for CVS Users

Anonymous's picture

The one thing that bugged me about this article..it does not define what tla stands for? Hmm, I'll have to see the arch home page for the answer.

Re: Arch for CVS Users

Anonymous's picture

TLA == "Tom Lord's Arch"

Re: Arch for CVS Users

Anonymous's picture

..Which is used for historical reasons. The initial implementation of arch was called "larch"; it was a collection of shell scripts (along w/ some C). It's was slow and messy; as expected, a few different reimplementations popped up. TLA was Tom Lord's rewrite of arch in C.

Here's a good summary:

Tom Lord's original implementation was at first named Arch, but was renamed to Larch because of a naming conflict. Its reliance on shell scripts was often pronounced less portable than alternatives. That issue and other considerations lead to creation of Walter Landry's C++ version, ArX, Robert Collins's C++ version, barch (reported to be defunct), Federico Di Gregorio's Python version, eva, and most recently Tom Lord's rewrite in C, tla

Re: Arch for CVS Users

Anonymous's picture

The thing I like about "tla" is that it is itself a TLA....

Which is to say, a Three Letter Acronym. :)

Re: Arch for CVS Users

Anonymous's picture

I hope more people take a good look at distributed version control systems. It would be sad if everyone just rushed off and adopted the only incremental improvements of Subversion.

That being said- I tried Arch for a few months and found it to be very complicated, the developers are confused (and admit it) as to whether they are developing a system for people to use or a prototype api. Their are frequently 2-3 commands for everything you might want to do and each one has different reasons to choose it based on the way you've setup Arch.

There is resistance at a high level to simplifying the commands because so many people have written different simplifying shell scripts that rely on the complicated commands.

The lead developer Tom Lord is developing a new version of scheme so that he can write a "user-level" version of Arch.

Monotone www.venge.net/monotone is what I've settled on. Much much cleaner and really even more powerful in it's distributed capabilities. Its much easier for you to develop, commit and then synch on multiple of your own machines than Arch. It's also more straightforward to adopt a more centralized development model. Monotone supports it pretty straightforwardly while Arch requires ssh+file system perms screwiness or "pqm" which is a separate server.

Anyway, I've chosen Monotone but I would choose Arch over the incremental improvements of Subversion anyday.

Re: Arch for CVS Users

Anonymous's picture
Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix