gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] State of the Arches


From: Tom Lord
Subject: Re: [Gnu-arch-users] State of the Arches
Date: Wed, 23 Mar 2005 14:30:39 -0800 (PST)


   From: Deliverable Mail <address@hidden>

   Once I started to look at tla, I see mentions of larch, baz, ArX, and
   some others.  There're also references to a legacy arch.  Can someone
   please summarize/point out the history of GNU Arch <=> tla, and
   outline, briefly, the main differences of other clones? 

`larch' was the first implementation of "the arch revision control
system".  It was mostly a set of shell scripts with a little bit of 
/awk/ and /C/ thrown in.

`tla', also known as /GNU Arch/, replaced `larch'.  It is 
written in /C/.

`ArX' is a fork of Arch that started back when `larch' was still
the only viable implementation.   Walter Landry was an early 
pioneer in the field of distrusting my leadership to the point of 
branching: he set out to reimplement `larch' in /C++/ and by all
reports has done quite well.  Of slight concern, perhaps, is that
`ArX' has fallen out of compatability, as far as I know, with `tla'
and `baz'.   It might be helpful, incidentally, for the greater
Arch community to help repair any residual personality rift between
Landry and I, at least enough to repair bidirectional compatability
between all branches.

`Baz' is a fork of Arch created by Canonical Corporation.  There 
is a lot of active disagreement about various day to day issues
between `tla' and `baz' hackers -- but it's so far been a productive
disagreement with the two branches staying in fairly close sync.



    E.g., baz
   refers to arch protocol, but already has its own archive format
   (although can work with tla format as well).

Why, just today I merged patches for bidirectional archive compatability.

There's no official rule or anything but, generally, it seems that both
the `baz' and `tla' maintainers feel the two branches should remain
bidirectionally compatible and, probably, pretty close in source text.

The "arch protocol" is the name for a platonic ideal world in which we
have perfect, formal standards documents for all the details of
operation that determine interoperability between two branches or
between present, past, and future versions of arch.  We'll get there
-- or at least a lot closer to there than we are now.


   How did tla come to
   become the GNU Arch?  And what is the deal with the clones, they seem
   to splinter the development and attention of those researching a new
   versioning system...  

I'm convinced, after seeing it work for a few months, that the baz
branch, at least, doesn't splinter development -- it optimizes it a
little bit.  There's too much pressure on the GNU branch to be
conservative with little bursts of accelarated change -- `baz'
relieves some of that pressure.

Archive format is a good example: the `baz' folks had plans for a
change; I had some objections --- we could have gone back and forth
for months before changing the GNU mainline: which end do you crack
the egg on stuff.  Instead, since Canonical had a pressing need, they
worked out their solution in `baz', proved it sufficiently in the
field, and now `tla' gets to snark it with just some tlc to smooth the
merge.  My objections to the format stand but, as a practical matter,
the existence of the baz branch with its separate priorities forced
the efficient creation of a working compromise (demonstrated patches
about which only minor complaints could be mustered).



   I'd like to see a statement from GNU on the

*This* statement is not an official statement from GNU although 
I guess its an official informal description of what an official
statement from the GNU Arch maintainer might be like :-)

   "State of the Arches", and/or at least "a view from the tla project,"
   since when you start looking at it, it's not immediately obvious who's
   the original, who's the clone, which is the viable and safe bet to use
   for the long term.

Depends on your requirements.  I'm certain I keep the non -preX GNU
releases in a condition I'd like to use them in for my needs, at least.
The -preX releases slip by accident but it's a designed-for kind of 
accident.

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]