Re: Gud lord!

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

On Sat, 2003-06-07 at 19:02, Miles Bader wrote:
> You're entitled to your opinion of course, but I've seen enough, from people
> that I trust, to feel cautious.

Cautious is good.  But I'm very interested to hear what you've "seen
from people you trust."  I contribute to arch and I'm always looking for
ways to improve it.

> Emacs is a fairly mature system, and has muddled along reasonably well with
> CVS's brain-damage, so there's little need to make any quick decisions.

I think people felt that way about ed before emacs came around.  etc.

> I'd guess that Emacs will probably switch too at some
> point, and probably won't be the last -- but I don't think it should be among
> the first.

I'd agree with that.  I never said "emacs needs arch today."  I merely
pointed out that stuff like the file renaming handcuffs are removed when
using arch.

> In fact, I _like_ the idea of switching to something new and cool because I'm
> as annoyed by CVS's bogosities as much as anyone (maybe more than most
> people -- as I use a slow modem link, and I understand that arch handles
> incremental updates much more efficiently than CVS [sending diffs both ways]),

For some use cases, it's much better than that, even.  If you're ok
with, say, daily updates from upstream, you can run a cron job to grab a
local mirror overnight, and get fully local disk performance for all
daily work.

> > They are defined by regexps.  I don't think regexps can reasonably be
> > considered "murky."
> 
> I think the issue was that this decision was based on names at all.  I seem
> to recall that there was a way to `register' files as well, but that there
> were issues with that as well.

No offense, but I'm pretty confident that any objections to the basic
architecture here are based on ignorance of what the architecture is,
and what it allows.  The basic reason being that the entire thing can be
made essentially isomorphic to CVS behavior in this area, if that's
really what you want, but it also allows much more flexibility and power
as well.  So it can't really be a step backward, and I'm pretty
confident that it's a powerful step forward.  There is possibly an issue
regarding defaults, but that is much less worrisome than questions about
basic architecture or functionality.

There's two layers here: the outer layer is based on naming conventions
to determine what files are _candidates_ for source, and the inner layer
is based on a "tagging method" (which granted, is possibly confusing
terminology for a CVS-head) which determines which of those files are
versioned.  The simplest "tagging method" is the very CVS-like "explicit
tagging" - which means you have an "add" operation to version a file in
the tree and a "delete" operation to stop versioning a file.  So with a
"naming convention" of "everything is source" and "explicit tagging,"
you're essentially looking at a very CVS-like system for determining
what files to version.  But there's much more to it, and for good
reasons that require considerable background and revctl mind-expansion
for the typical person coming from a CVS background.

Now, regarding this idea of "naming conventions" that people seem to be
skeptical of:  find me a seasoned programmer who doesn't have a script
or alias or some mechanism which is used for finding or grepping through
files he's interested in in a source or project tree.  I've had "sfind"
and "sgrep" and "mktags" (source find/grep, tag source files) scripts
for 10 years, which filter out files which I don't want polluting my
searches for things in my source tree (say, CVS control files or core
files or dot-oh files).  This is the spirit of the "naming conventions"
in arch.  It standardizes and builds this kind of functionality right
into the revctl, per-project.  Think of naming conventions as a
specialized and customizable find command for source trees, because that
is exactly the functionality it provides.  It's loosely related to the
idea of .cvsignore in CVS but much more powerful.

> BTW, thank you for posting this, because at the least, it's some impetus to
> look more closely at the current state of things.

No prob.  I don't mean to push, but I think it's important to remind
people that alternatives exist when they complain about limitations of
their current tools.

Bob