Revision Control with Arch: Introduction to Arch

 in
Whether you're moving up from CVS or just getting serious about a revision control system, here's a powerful tool that will keep records of changes and keep your projects under control.
Merging Projects from Two Different Archives

Of course, while you work on your branch, development may have continued on the original archive. Running tla update fetches changes only from your local branch and not the original project. To fold in changes from upstream, you need to star-merge:


$ tla star-merge \
lnx-bbc-devel@zork.net--gar/lnx-bbc--stable--2.1

In the event of conflicts (situations where both your branch and the upstream project have changes to the same lines of code), Arch uses the standard patch method of creating .orig and .rej files for each file that has conflicts. It is a good idea to use the find utility to seek out any rejects before committing your star-merge.

Speeding Up Archive Operations

You may have noticed that revisions are named either base-0 or patch-#, where # is the number of patches to base-0 that must be applied. Arch uses a log-structured archive format, so that archive operations only ever add information to a project. This means that for big projects with many revisions, it can take a long time for certain tasks.

To speed up operations, you can make a snapshot of a given revision. Arch snapshots are simply a compressed tarball of a checked-out revision. When a checkout or other operation is performed, Arch looks for the highest-numbered snapshot and applies any necessary patches from there:

$ tla cacherev

Once this is finished, you can run tla cachedrevs to see what revisions have snapshots within your archive:

lnx-bbc--robot-branch--0.0--base-0
lnx-bbc--robot-branch--0.0--patch-1

Libraries

Because you do not always have access to create snapshots in an archive, it can be useful to make a local cache to speed up file operations. Arch provides a second kind of cache, called a library, that stores copies of checked-out files from various revisions. This is especially helpful for remote archives, because it means you do not even need to download the base snapshot revision before applying changesets:


$ mkdir ~/LIBRARY
$ tla my-revision-library ~/LIBRARY
$ tla library-config --greedy ~/LIBRARY
$ tla library-add \
  lnx-bbc-devel@zork.net--gar/lnx-bbc--stable--2.1

This library is not small, with the example above comprising over 78MB as of June 2004. The advantage over a slow link, however, is well worth the trouble. In addition, laptops often have slow ATA hard drives, and involved archive operations can be a drag as the drivers use up plenty of CPU cycles. A greedy (auto-updating) Arch library can make your revision control operations quicker and more responsive, even for local archives.

More to Come

In the next article in this series, you'll learn how to make publicly available mirrors so that upstream developers can star-merge back from your branches. In addition, you'll learn how to cherry-pick changesets from a busy branch and how to use GnuPG to sign your changesets cryptographically for security purposes.

The third and final installment of this series will describe centralized development techniques with Arch. You'll learn how to manage a shared access archive using OpenSSH's SFTP protocol and how to write scripts to perform automated tasks on your archives.

Resources for this article: /article/7752.

Nick Moffitt is a Linux professional living in the San Francisco Bay Area. He is the build engineer for the LNX-BBC Bootable Business Card distribution of GNU/Linux and the author of the GAR build system. When not hacking, he studies the history of urban public transportation.

______________________

Comments

Comment viewing options

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

Larry McVoy at SCALE 3x

Anonymous's picture

If you're interested in revision control software Larry McVoy of BitKeeper fame, will be speaking about distributed revision control systems at the upcoming Southern California Linux Expo

Re: Revision Control with Arch: Introduction to Arch

Anonymous's picture

Posted on Monday, November 01, 2004 by Nick Moffitt

Damn lag...

Re: Revision Control with Arch: Introduction to Arch

Anonymous's picture

I thought TLA was Three Letter Acronym.

Re: Revision Control with Arch: Introduction to Arch

f15_eagle's picture

I had played around with arch (and arx) a while ago and also found it fairly confusing. I was reading this hoping that things have changed for the better, but it doesn't sound like it has.

Reason being that I've got two areas I do development on that can't talk to one another via a network, yet I'd like to keep their CVS repositories sync'd up. One option would be to copy the repositories over, but I didn't start out that way. I made two separate repositories and just grab snapshots from one and integrate it to the other using CVS tags to manage revisions.

This works ok, but seems a little clunky. If I'm reading it right, arch be a natural for such an environment, once I get past the initial learning curve.

Any thoughts?

Re: Revision Control with Arch: Introduction to Arch

Anonymous's picture

I am pretty sure Arch would be a good fit. You'd probably do something like this:

Create an Arch archive at Site A and an Arch archive at Site B. Commit any changes into the archive where you are at.

Create an Arch archive on a USB stick. Use 'tla star-merge' to merge the site archive with the USB stick archive.

Re: Revision Control with Arch: Introduction to Arch

Anonymous's picture

well, I tried tla. It's horrible complicated. Until you find out how it works, you have set up 10 local subversions. Seriously. I think its not worth, even if subversion might have some downsides.

Re: Revision Control with Arch: Introduction to Arch

Anonymous's picture

So a GUI arch is needed.

Not a GUI, just a sane interf

Anonymous's picture

Not a GUI, just a sane interface.

Re: Revision Control with Arch: Introduction to Arch

Anonymous's picture

Actually, "tla" stands for "true love always", not "tom lord's arch"
although the coincidence of acronym there is part of why the
name "tla" was chosen ("tla", as acronym, provides lots of
plausible deniability --- for example, it also stands for "three letter
acronym".)

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