An Interview with Tom Lord of Arch (O'ReillyNet)

Posted Sep 25, 2004 1:03 UTC (Sat) by dwheeler (guest, #1216) [Link]

"GNU arch gives you a lot of control using lower-level commands, but it doesn't (yet) automate a number of tasks that it really should be automating. Many common operations require multiple commands, when instead a single command and reasonable options should be enough for most people. If you use a single archive for a long time in GNU arch, it eventually accumulates a very large amount of data and becomes inconvenient to work with. arch's developer suggests dividing archives by time and including a date in the archive name. I think handling this accumulation is a nuisance; this kind of manual work is exactly what an SCM should handle automatically (e.g., perhaps arch could hide branches that have been unused in more than a year, by default). Arch has nice caching facilities (both in archives and on individual workstations) which can speed access to specific versions. However, these caches often have to be created by hand (by default the tool should automatically create caches, and remove old automatically-created caches, as well). Arch works slowly if the {arch} directory is on NFS; the tool should be able to detect slow execution and automatically try to find an efficient alternative, instead of requiring user workarounds. Many arch developers seem to create a similar set of higher-level specialized scripts to automate common tasks, but that's missing the point: you shouldn't have to write scripts to make a tool automate common tasks. An SCM tool should include commands that, through automation and good defaults, 'do the right thing' for common tasks. The good news is that the arch developers are realizing that this is a problem and correcting it. The rm (delete) command deletes both the id and the corresponding file automatically (instead of requiring two steps); that capability was only added on February 23, 2004, though, so clearly automating steps has only begun. The documentation notes that automatic cache management is desirable; it just hasn't been done. The mirroring capability is clever, but if you download a mirror and make a change, you can't commit the change and the tool isn't smart enough to automatically help (even though the tool does have information on the mirror's source)."

Another real problem is that arch doesn't support Windows well. That means that if you might ever have to work with any project where there's a single Windows user, you can't use arch... and since people don't like to have to learn many different SCM systems, that's a real impediment for everyone.

That doesn't mean that I think GNU arch is hopeless, at all. Here's what I said: "But don't count out GNU arch for the long term based on these problems, most of which are short-term. Many of these problems simply reflect the fact that GNU arch hasn't had as much time to mature as other tools like subversion. I'm documenting these problems because, in fact, GNU arch has a lot going for it. In my opinion, the GNU arch developers have emphasized simplicity, openness of design, and power (ability to handle complex situations), and have paid less attention so far to ease of use (especially for simple situations). Thus, although it has problems as noted above, GNU arch is extremely powerful and its basic concepts are very flexible."