[Gnu-arch-users] What is arch? (Alternative answer)

[Pierce T . Wetter III]

  Since I don't really like how the current documentation describes 
things, I guess its up to me to rewrite it. Comments appreciated, if 
not required, since I'm writing this as I go through the tutorial for 
the 3rd time trying to understand it.

 Ultimately I want this to be a "Gentle introduction to arch for CVS 
users" document.


 What is Arch?

 arch is a "source history management system" that many people use to 
implement "revision control" though it can do more then just revision 
control. Its an outgrowth of some scripts Tom Lord wrote to automate 
some of what he considered "best practices" of tracking changes to a 
set of source code.

 Whether you are one developer or many, as you change your source code, 
you are creating a history of changes to that source. This is of 
course, not news, most developers have some experience with using some 
sort of "revision control" system to manage that history. Most of these 
systems rely on a central repository, and assume a sort of tree 
structure. That is, there is a concept of a "central trunk", with 
occasional "branches" off that trunk when a developer has to "break 
stuff" in order to get some new feature working. Depending on the 
revision system, branching can be easy or hard, but the challenge it 
all of them turns out to be merging changes between the trunk and the 
branch.

This is less true in arch, because arch assumes a model much closer to 
a spiderweb then a tree. Since this is actually much closer to how 
developers actually work, once they get used to it, most developers 
prefer it, and arch seems more natural. Because of its different 
approach, arch ends up being more capable at dealing with many of the 
common problems people run into with traditional revision control. 
Specifically, arch is really, really good at merging changes

 What is tla?

 arch is actually a protocol for how a source history management system 
would work. tla is an implementation of that protocol in C. There are 
some other implementations of arch in other languages.

 arch advantages

 - parallel lines of development are easier. This is the very common 
development
   occurrence where you need a bug fix in the upcoming release and you 
also need
   it in the development trunk. This is as opposed to "branching" where 
moving
   changes between branches can be more complicated.

 - source repository is in open formats like tar, gzip.

 - supports a number of development styles: no assumptions about work 
flow
   or repository is built in to tla.

 - read-only source repository can be just a web server.

 - built in mirroring and replication

 - very network efficient,

 - most operations can be done offline, only updates from _others_ 
would need
   any sort of connection, but even sneakernet works there.

 - spiderweb model means that developers can work together on tasks 
more easily.

 arch disadvantages

 - read/write access requires setting up a webdav server like apache

 - no tla package easily available for Windows since tla leverages off 
of
   various unix command line tools. Not sure about other implementations

 - basic tla commands are simple, primitive, most people end up 
building scripts
   to automate their local development style, but rarely document and 
share them.

 Differences from CVS:

  arch has a very different model then CVS, but it supports all the 
features of
  CVS in a different way. Coming from CVS will be quite a shock for 
most users
  because of this. Here are some highlights:

  - no central repository. CVS has a definite concept that there is one 
single
    repository where everything lives. In arch, that is a site 
decision, you can
    set it up that way if you so choose. In practice, most arch users 
end up
    having a "blessed" repository, but that is different then having a 
central
    repository.

  - merge history, not "commit"

    branching and tags are so much a part of arch that its probably 
fair to say
    that in arch, everything is a branch. That might sound scary to a 
typical CVS
    user, unless you realize that the minute you check out a revision 
from CVS,
    then start editing it, you've created a branch, CVS just doesn't 
know about
    it. In arch, the "commit" is really a process of merging your source
    history with that of your upstream archive, so branching is 
seamless and
    obvious.




Later:

 What is an archive:

  An archive is the history of changes to a project or set of projects. 
Since that history is always growing, an archive has the concept of an 
ancestor archive which holds the "earlier" history. Arch can 
automatically extract revisions from ancestor archives, so its common 
to make a new archive every so often to shrink the amount of data 
needed for a build of the latest source. It's also common to have 
multiple archives for multiple projects, but not necessary.


 That's it for now.

Pierce