Arch for CVS Users
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.
tla register-archive http://www.lnx-bbc.org/arch tla get email@example.com/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 firstname.lastname@example.org). 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:
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".
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.
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://email@example.com/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.
|Free Today: September Issue of Linux Journal (Retail value: $5.99)||Sep 27, 2016|
|nginx||Sep 27, 2016|
|Epiq Solutions' Sidekiq M.2||Sep 26, 2016|
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- Android Browser Security--What You Haven't Been Told
- Readers' Choice Awards 2013
- Epiq Solutions' Sidekiq M.2
- The Many Paths to a Solution
- Nativ Disc
- Downloading an Entire Web Site with wget
- Returning Values from Bash Functions
- Securing the Programmer
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide