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

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

On Sat, 2003-06-07 at 20:05, Alan Shutko wrote:
> Robert Anderson <rwa@alumni.princeton.edu> writes:
> 
> > They are defined by regexps.  I don't think regexps can reasonably be
> > considered "murky."
> 
>   Some people, when confronted with a problem, think "I know, I'll use
>   regular expressions."  Now they have two problems.
>                                          - Jamie Zawinski[1]

I believe that's "borrowed" from the original quote about awk, which I'm
not sufficiently motivated to look up.

If regexps are somehow unacceptable, then I think emacs has deeper
problems than arch does.  If people really really need, say, shell globs
instead, that could be added in a few lines of code.

> > 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."  
> 
> Any changes the system go through will have to be tracked by someone.
> If the existing CVS crew were to admin arch as well, they'd be even
> more overworked.

There isn't really an "admin" for arch the way there is for CVS, because
it is not a centralized system.

  Otherwise, Emacs developers would have to learn
> everything about arch, at the cost of doing Emacs development.

Well sure, but by that argument no developer would learn any tool,
including emacs, because it would take time away from doing something
else.  That would of course not be an advisable path to maximal
productivity, IMO.

  (And
> it would be nice to get a release out sometime.)  This change will
> also impact all of the Emacs developers, taking time away from any of
> their development.

If I was going to propose a migration, which I'm not, I would propose it
in a way that would make such a statement patently false.

> Any time the software needs to get upgraded, or file formats get
> changed, or the user-defined naming conventions turn out to be
> ill-advised and need to be changed, productivity on all levels will
> be hurt.

Of course such things have to be weighed against what you get out of the
trouble.

> > The only thing that needs to be worked out about those other things
> > is users' understanding of them.
> 
> Sure... and that takes time and effort that could be spent stabilizing
> Emacs so that a release with new features can get out.

Perhaps if emacs was using arch it would have 2x the contributors, since
contributions could be done without requiring CVS write access to begin
or work on significant contributions, and releases would get out faster
than before.  The amount of evidence for your assertions about lost
productivity are comparable to mine about increased productivity.

> And since arch is immature, it means that all the best practices have
> yet to be figured out.

The lowest hanging fruit in "best practices" for revctl has been
well-known for ages.  You'd like to be able to rename files.  You'd like
to be able branch conveniently and merge those branches conveniently. 
You can get that stuff right away with no experimentation.

> Why force that on Emacs developers?

Where have I forced anything on anybody?  I'm simply stating some facts
interspersed with some opinions about revctl.

> No matter how mature arch is, or how well-documented the transition
> steps may be (like importing the multiple active branches currently
> under development in a sane way) it would still take work and cause a
> bunch of disruption.  And for the ability to rename files[2] it's
> certainly not worth it.

Agree.

> For the rest of the features, it may be
> worth it... or maybe svn would be better[3], or maybe something
> else.  But that decision can wait.

Wait for what, I wonder?

> [3]  which _does_ offer a CVS->SVN conversion tool....

Such notions of "archive conversion" are deeply ill-conceived, IMO.  I
see no compelling reason to "fake" development history and many reasons
not to.

Bob