[Fwd: [arch-users] Re: Gud lord!]

[Robert Anderson <rwa@alumni.princeton.edu>]

From: Robert Anderson <rwa@alumni.princeton.edu>
To: Miles Bader <miles@gnu.org>
Cc: arch <arch-users@lists.fifthvision.net>
Subject: [arch-users] Re: Gud lord!
Date: 07 Jun 2003 17:28:04 -0700

On Sat, 2003-06-07 at 16:47, Miles Bader wrote:
> Dicsussions of whether to switch to arch or subversion are not uncommon, and
> what I've seen so far always manages to bring up `issues' with the various
> revision control systems.

I'd venture that a lot of such discussion as seen on various well-known
discussion sites has often bordered on the inane, mostly from hastily
drawn conclusions about a poorly understood system which does take some
time to understand and appreciate (much like emacs, IMO).

  It's not always `it lost all my files!'  For
> instance in the case of arch, Tom Lord's original implementation is
> apparently unusably slow in some cases

On cygwin, yes, unusably so.  No good solution for windows exists to my
knowledge.  Otherwise, the sh implementation: yes, slow, but not
unusably, IMO.  Unusably slow performance is probably user error.  And
the new C translation is aimed at (and getting) dramatic performance
improvements.

; I guess there's alternative
> implementation (in the works?) but that's still somewhat new (and so to be
> treated with caution).

Yes and no.  The core commands have actually been extensively and
systematically tested and were much more solid out of the gate than the
original implementation (the orig impl. has since been fixed as well).

  Some other issues with arch that often come include
> (1) the somewhat murky rules/conventions for designating source-controlled
> files,

They are defined by regexps.  I don't think regexps can reasonably be
considered "murky."

 and (2) the naming conventions, which reflect Tom Lord's somewhat
> wacky and idiosyncratic tastes, and put some people off.

This is a common misunderstanding.  "Naming conventions" in arch are
_user-defined_.  You can use whatever you like.  Tom uses some
idiosyncratic stuff in _his_ source trees, it is true.  But you don't
have to in your own.

> Now all these things will eventually be worked out -- but that's the point:
> arch is not yet a stable system, it's still undergoing change.

I don't see how you can say that it is not stable.  The core of the
system has been stable for a long time.  I don't see how performance
improvements can be considered "instability."  The only thing that needs
to be worked out about those other things is users' understanding of
them.

> I certainly am no expert on any of these systems, and am relying on the
> `buzz' for my info -- but I think in this case that's proper thing to do.

Well frankly the buzz borders on the inane quite often, and the
propagation of disinformation - like your two points about "naming
conventions" - is really frustrating for people who know better.

If I were to dismiss emacs out of hand because there are "too many
parentheses", I don't think you would respond by removing lisp as an
extension language or by conceding that emacs isn't usable yet.  You
would state your good reasons for using lisp as an extension language,
and stick to your guns that you will not compromise a good design
decision because I am uneducated about lisp.  This is how many who have
been around arch for awhile feel at this point when listening to the
aforementioned "buzz."

> [another thing about arch I've wondered about is the use of FTP as a remote
> protocol -- though I have no idea whether it's easy/practical to use
> something else instead.  For better or for worse, ftp access is problematical
> in many cases (including my own!); subversion's standard use of http is much
> more practical.]

Are ftp, http, webdav, ssh, and freenet sufficient?  Because arch does
them all (freenet is contrib code).

> > I'm also curious what you mean by "well supported."  I can't think of a
> > free software project in existence that has a more dedicated maintainer
> > than arch does.
> 
> Stefan gave a good answer to this.

See my response.  Most of said tools do already exist.

Bob