Revision Control with Arch: Maintenance and Advanced Use

Put a powerful revision control system to work for you with only Web and SSH software on the server side. Here's what you need to administer a software projet with Arch.
Mirrors

In the above cherry-picking example, Alice B. Hacker used a Web-accessible directory for her personal archive. This is convenient, but it poses a problem for disconnected use. What if Alice wanted to work from her laptop during a long airplane flight or train ride? She either would have to generate changeset tarballs with tla changes or star-merge her various branches manually one by one from her laptop to her Web-space archive when she reached a network connection. Fortunately, Arch permits the creation of archives that are simply mirrors of other archives:


$ tla make-archive -ls --mirror-from \
  jrh@zork.net--signed \
  sftp://jrh@zork.net/public_html/arch/

In this instance of make-archive, J. Random Hacker is creating an archive in his public_html directory on an Internet server. Once the mirror archive is created, it shows up in a tla archives listing as jrh@zork.net--signed-MIRROR. Now data can be pushed to it with a single command:


$ tla archive-mirror jrh@zork.net--signed

In addition to push mirrors that copy local archive data to remote systems, Arch allows pull mirrors that create local copies of remote archives:


$ tla make-archive -ls --mirror \
  lnx-bbc-devel@zork.net--gar \
  /var/tmp/gar-cache
$ tla archive-mirror lnx-bbc-devel@zork.net--gar

This can be handy during disconnected operation, when a local branch may not be sufficient. Pull mirrors allow read-only access to a remote archive's data while off the Net.

Signed Mirrors

One drawback to the jrh@zork.net—signed-MIRROR archive is that it is a separate signed archive in its own right. This means J. Random Hacker must sign each changeset as it is copied from the original archive to the mirror.

In some cases, this is the desired effect. A release manager personally vouches for each changeset that enters the public mirror, for example. In most cases, however, it is important simply to copy the existing signatures along with the changeset. This is achieved by creating a special file on the system where tla archive-mirror is run:


$ echo jrh@zork.net--signed > \
  ~/.arch-params/signing/jrh@zork.net--signed-MIRROR

Working Off-line (Even If You're Absent-Minded)

Mirrors are extremely useful, but they are, by nature, read-only. The only way changes can be committed to a mirror is through the original archive by way of tla archive-mirror.

Consider Alice's laptop mirror situation. While sitting in the observation car of Amtrak's Coast Starlight, she pulls out her laptop and does tla get to grab some code out of a local mirror of abh@zork.net--work. Somewhere in the Willamette Valley, she finds inspiration and completes a remarkably useful hack.

Any attempt to commit her changes would receive the message attempt to write directly to mirror, which means the commit failed. The simple solution is to wait until she reaches an Internet access point and use the undo and redo commands:

$ tla undo ,changes-to-mirror
$ cd ~/real-project/
$ tla redo ~/mirror-checkout/,changes-to-mirror/
$ tla commit

This works fine if your changes are not enough to require more than one changeset. For longer detached sessions, you'll want to make a new local branch.

After her trip down the Pacific Coast, Alice takes the Zephyr to Chicago. It is a longer trip, and she found herself working in a local mirror of bob@entar.net--code on the foo--stable--2.4.2 code. After a few hours of work, she decides to move her changes to a new branch.

First, she makes a new archive and branch on her laptop:

$ tla make-archive -l abh@zork.net--laptop ~/arch
$ tla my-default-archive abh@zork.net--laptop
$ tla archive-setup foo--laptop-hacks--1.0

Next, she tags off the mirror branch to her new archive. She runs the tla logs command in shell backticks so she doesn't have to remember which patch level and version she was working in at the moment:


$ tla tag `tla logs -r -f | head -n 1` \
  foo--laptop-hacks--1.0

Finally, Alice coerces the checked-out copy into believing it is the first revision in her new laptop-hacks branch:

$ tla sync-tree foo--laptop-hacks--1.0--base-0
$ tla set-tree-version foo--laptop-hacks--1.0

At this point, she has shifted her checked-out copy from the read-only mirror over to a read-write archive hosted on her laptop.

______________________

Comments

Comment viewing options

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

I cannot find the 3rd

Anonymous's picture

I cannot find the 3rd installment of this great Arch tutorial.
It would appear that Linux Journal left it out for some reason.
There is another Linux Journal article by the same author titled "Arch for CVS users", but it appeared before the other two. There also was a tutorial on an earlier version of Arch in 2002 (when the utility was still named larch).

Regardless, I feel overwhelmed by the variety of improved CVS and project management systems with different philosophies out there. I would love to see an LJ article comparing the different options and listing some pros and cons. In particular, Arch vs. Subversion has been a hot topic lately. Now there is GIT. Where does it stand?

Where to find part 3 of this article

Bernt Hansen's picture

Hi,

I can't seem to find the 3rd part of this article... is it available somewhere?

Thanks,
Bernt.

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