arx-users
[Top][All Lists]
Advanced

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

Re: [Arx-users] ArX and tla


From: Walter Landry
Subject: Re: [Arx-users] ArX and tla
Date: Tue, 06 Jan 2004 22:53:49 -0500 (EST)

Felix Breuer <address@hidden> wrote:
> Hello Walter!
> 
> I have just come across larch, tla and arx and I read that arx is a fork
> of the arch project. I also read in one of your previous mails on this
> list that the projects forked because you and Tom had different ideas
> about how the project should evolve. 
> 
> What are your plans for ArX as opposed to Tom's plans for tla?

If you want a short-term vision for ArX, then

  http://mail.gnu.org/archive/html/arx-users/2003-08/msg00001.html

is still pretty accurate, though I have had a few more ideas since
then.  I have made substantial progress in the C++ rewrite, and it has
already cleared up a number of small bugs and a significant security
hole.  Once the rewrite gets done, things like Internationalization
become possible.

I don't know that Tom has a specific short-term vision for what he
wants in tla.

As for long term differences, I would say that a big one is how much
should a version control system determine policy.  For example, both
ArX and tla require that an archive be preceded by a valid looking
email address.  I do not plan to keep that restriction, so you could
use a descriptive phrase to name your archive.

I also tend to favor putting more convenience functions inside the
version control system itself.  The original implementation was far
too low level.  Tom seemed to want every user to become an expert on
the implementation of version control systems.  I haven't completely
kept up on tla, but it seems like Tom is improving in that respect.  I
also tend to include more tools with ArX itself (like bash completion
or an emacs mode).

There is also the technical difference that I prefer writing in C++
and Python, while Tom is more of a C and Scheme guy.  I don't care for
Tom's C code, and one of my goals is to replace all of Tom's code with
something more portable and robust.

I feel like I am much more concerned with security and robustness than
Tom.  For example, Tom has chosen to speed up tla in a manner similar
to what Stellation has already had problems with.  I am also the one
who found the security problems referenced in

  http://mail.gnu.org/archive/html/arx-users/2003-10/msg00000.html
  http://mail.gnu.org/archive/html/gnu-arch-users/2003-11/msg00036.html

tla had a fair number of memory bugs (too many or too few free's) and
unclosed files, though that seems to have settled down.  One of the
reasons I prefer C++ is because I can program in a manner that avoids
these problems.  For example, there isn't a single new() or malloc()
in all of the ArX C++ code I've written.

My current plan is to implement checksums and signed archives
according to

  http://mail.gnu.org/archive/html/arx-users/2003-11/msg00004.html

which I believe is different from the way that tla has done it
(although they don't seem to have completely decided what they are
doing).

Tom has a great affinity for implicit (which have now morphed into
tagline) inventories, while I prefer explicit inventories.  Those
affinities will probably be reflected in how much we support the
various inventory methods.  For example, the inode optimizations in
tla do not work for explicit inventories.  I do still plan to support
other inventory methods.  I may add another method, similar to what
Perforce and Bitkeeper have, which would significantly speed up
operations for large trees.  Tom seems unlikely to.

Finally, we have differences over what free documentation is.  I have
recently finished rewriting all of Tom's documentation, so ArX is now
completely free.

> (I need to choose a new version control system and I am not sure
> which bus I should hop on to, so to speak :)

There are a number of them out there.  The site

  http://linuxmafia.com/faq/Apps/scm.html

has links to all the ones of importance that I know of.  I use ArX
every day, and I would certainly recommend it.  There are still some
basic limitations like internationalization (e.g. umlaut's in file
names may cause trouble), and I can't vouch for Windows compatibility.
Those will get fixed, since they will eventually affect me directly.

Regards,
Walter




reply via email to

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