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

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

[Robert Anderson]

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

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

[Alan Shutko]

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 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.  Otherwise, Emacs developers would have to learn
everything about arch, at the cost of doing Emacs development.  (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.

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.

> 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.

And since arch is immature, it means that all the best practices have
yet to be figured out.  Why force that on Emacs developers?  Let
other people figure out things so that Emacs can tread in their
footsteps and not waste too much time to the transition.

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.  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.

Footnotes: 
[1]  http://groups.google.com/groups?selm=33F0C496.370D7C45%40netscape.com

[2]  Yes, that's where you brought this up.

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

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
No two equals are the same

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

[Robert Anderson]

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

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

[Stefan Monnier]

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

That's the theory ;-)


	Stefan

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

[Stefan Monnier]

> > [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.

Remember the original post your responded to ?
The one where I complained that the problem with moving files
in CVS is that getting the past history becomes painful ?


	Stefan

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

[Robert Anderson]

On Sun, 2003-06-08 at 08:54, Stefan Monnier wrote:
> > > [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.
> 
> Remember the original post your responded to ?
> The one where I complained that the problem with moving files
> in CVS is that getting the past history becomes painful ?

Of course.  What about it?  If you think "archive conversion" is a
solution to that problem in any sense, I'd be interesting in hearing how
you think so.

Bob

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

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 1568 bytes --]

On Sat, Jun 07, 2003 at 10:05:05PM -0500, Alan Shutko wrote:
>  Some people, when confronted with a problem, think "I know, I'll use
>  regular expressions."  Now they have two problems.
>                                         - Jamie Zawinski[1]

Mr. Zawinski is incredibly arrogant, and his pronouncements need to be
taken with a large dose of salt.

>more overworked.  Otherwise, Emacs developers would have to learn
>everything about arch, at the cost of doing Emacs development.  (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.

I can't take the time to learn how to use that wheel-barrow, I have a
foundation to dig; I'll just keep carrying the dirt over to the pile a
shovelful at a time.

>And since arch is immature

Arch is usably mature, with multiple implementations in various
languages.

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Alan Shutko]

Jonathan Walther <krooger@debian.org> writes:

> I can't take the time to learn how to use that wheel-barrow, I have a
> foundation to dig; I'll just keep carrying the dirt over to the pile a
> shovelful at a time.

That's a very bad analogy, since CVS is currently working, you just
have pain when renaming files.

(Besides, it doesn't make sense.  Does anyone dig foundations by hand?
If you are, your wheelbarrow is the least of your problems.  Maybe you
could have an analogy with construction equipment, but if asked in the
middle of a task to switch and retrain on new equipment with a
completely different interface and design philosophy, most builders
would laugh at you.)

>>And since arch is immature
>
> Arch is usably mature, with multiple implementations in various
> languages.

How many years of experience has arch had?  The implementation(s) may be
perfectly mature, but that doesn't mean that people's understanding of
it is.

If you'd like to see Emacs using arch, since arch is so decentralized,
maybe you or Robert could start maintaining an Emacs arch repository.
You could then figure out what the best setup for Emacs development
would be, which would make it much easier for an eventual wholesale
switch, since the rest of the developers could take advantage of your
knowledge.

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/

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

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 1568 bytes --]

On Sun, Jun 08, 2003 at 08:47:19PM -0500, Alan Shutko wrote:
>> I can't take the time to learn how to use that wheel-barrow, I have a
>> foundation to dig; I'll just keep carrying the dirt over to the pile a
>> shovelful at a time.
>That's a very bad analogy, since CVS is currently working, you just
>have pain when renaming files.

It's a good analogy; the shovel works as well as CVS does.  Although you
could make another analogy:  I can't take the time to learn to use that
backhoe, I have a foundation to dig; I'll just keep using this
wheelbarrow and shovel.

>If you'd like to see Emacs using arch, since arch is so decentralized,
>maybe you or Robert could start maintaining an Emacs arch repository.

My attention is focused on Xouvert, a source tree bigger and hairier
than emacs.  I am waiting for the first version of arch that integrates
the C code into one binary, then I will be announcing it to the world.

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Juanma Barranquero]

On 07 Jun 2003 22:01:29 -0700
Robert Anderson <rwa@alumni.princeton.edu> wrote:

> 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

People does contribute to Emacs every day without write access to CVS.
Read access and an e-mail account is all you need to contribute
(programming skills aside, of course). Installing the stuff is logically
different from contributing.

                                                                Juanma

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

[Robert Anderson]

On Mon, 2003-06-09 at 01:23, Juanma Barranquero wrote:
> 
> On 07 Jun 2003 22:01:29 -0700
> Robert Anderson <rwa@alumni.princeton.edu> wrote:
> 
> > 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
> 
> People does contribute to Emacs every day without write access to CVS.
> Read access and an e-mail account is all you need to contribute
> (programming skills aside, of course). Installing the stuff is logically
> different from contributing.
> 
>                                                                 Juanma

Sure, and people could contribute if you read them the source over the
phone as well.  That's all they would "need."  Would you contribute if
that's all the facility you had?  It's not optimal, and neither is
working in an non source controlled environment for developing
substantial contributions.

Bob

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

[Robert Anderson]

On Sun, 2003-06-08 at 18:47, Alan Shutko wrote:
> Jonathan Walther <krooger@debian.org> writes:
> 
> > I can't take the time to learn how to use that wheel-barrow, I have a
> > foundation to dig; I'll just keep carrying the dirt over to the pile a
> > shovelful at a time.
> 
> That's a very bad analogy, since CVS is currently working, you just
> have pain when renaming files.

Well that's false.  You have many other sources of pain as well, some of
which you might not have realized were painful until you've used a
better tool.

> How many years of experience has arch had?  The implementation(s) may be
> perfectly mature, but that doesn't mean that people's understanding of
> it is.

Agree.

> If you'd like to see Emacs using arch, since arch is so decentralized,
> maybe you or Robert could start maintaining an Emacs arch repository.

If I was going to do that, it would not be for emacs.

Bob

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

[Juanma Barranquero]

On 09 Jun 2003 07:37:24 -0700
Robert Anderson <rwa@alumni.princeton.edu> wrote:

> Sure, and people could contribute if you read them the source over the
> phone as well.  That's all they would "need."  Would you contribute if
> that's all the facility you had?

I did (not the phone, the read-only access). Many people *do*, as I've
said. I know, I end commiting quite a few of these patches.

And forgive me, but the "phone line" example is a bit ridiculous.
Read-only access to CVS repositories is tried and true. It's not perfect,
but is not *that* bad.

arch, subversion, even BitKeeper if it was free, would perhaps be better
than CVS; I'm not arguing against that. Just that CVS and read-only
access aren't as great deterrents as you make it sound. Just take a look
at the very big and successful projects whose source control system is
CVS. Anyway, if I had to vote, I'd chose to wait for subversion.

> It's not optimal, and neither is
> working in an non source controlled environment for developing
> substantial contributions.

No, it's not optimal, and certainly I don't remember having said it was.
But even now there are people who does big contributions (I mean, not
tiny patches of 5-10 lines, but changes of hundreds or thousands of
lines) and who do not have write access nor (seem to) want it.

                                                                Juanma

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

[Kai Großjohann]

Robert Anderson <rwa@alumni.princeton.edu> writes:

> Well that's false.  You have many other sources of pain as well, some of
> which you might not have realized were painful until you've used a
> better tool.

I understand that branches cause pain amongst the Emacs developers.
-- 
This line is not blank.

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

[Miles Bader]

On Mon, Jun 09, 2003 at 05:00:16PM +0200, Juanma Barranquero wrote:
> > It's not optimal, and neither is working in an non source controlled
> > environment for developing substantial contributions.
> 
> No, it's not optimal, and certainly I don't remember having said it was.
> But even now there are people who does big contributions (I mean, not
> tiny patches of 5-10 lines, but changes of hundreds or thousands of
> lines) and who do not have write access nor (seem to) want it.

Indeed; I do a lot of development for projects where I don't have write
access (e.g., the linux kernel), and life is quite fine with a few shell
scripts to help me out.  Actually the thing which I find makes the most
difference is having at least read-only CVS access -- that's enough to make
it easy for me to keep things in sync and make patches; write access, by
comparison is rather a minor convenience.

[The time when I most appreciate having write access, actually, is when I
want to make a little random tweak (e.g. fix a typo), and don't have to
bother someone to check it in.]

I think for me, improvements in the standard patch-format to support things
like file renames would be at least important as a better revision control
system.  [Maybe arch actually addresses this, since I gather it tries to use
a very tool-oriented approach...]

-Miles
-- 
We live, as we dream -- alone....

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

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 1886 bytes --]

On Mon, Jun 09, 2003 at 05:00:16PM +0200, Juanma Barranquero wrote:
>arch, subversion, even BitKeeper if it was free, would perhaps be better
>than CVS; I'm not arguing against that. Just that CVS and read-only
>access aren't as great deterrents as you make it sound. Just take a look
>at the very big and successful projects whose source control system is
>CVS. Anyway, if I had to vote, I'd chose to wait for subversion.

We built la Sagrada Familia in Barcelona with pick axes, trowels and
spades, so there really isn't that great a benefit to using backhoes,
cranes, and dumptrucks.

>But even now there are people who does big contributions (I mean, not
>tiny patches of 5-10 lines, but changes of hundreds or thousands of
>lines) and who do not have write access nor (seem to) want it.

This isn't about write access; this is about having your local branch be
under revision control in a form that is really easy for the main branch
to pull in and merge, and that anyone can download if they want to.

Arch is about making branching a non-hostile and not necessarily
permanent act; it is about allowing many different threads of
developement to grow in parallel, instead of each fork diverging
irrevocably into different sunsets.

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Stefan Monnier]

I have no idea what you people are trying to do.
I think every Emacs developer agrees that it would be great to use
another system, whether Meta-CVS, Subversion, OpenCM, Arch, you name it.
I personally have a preference for either Meta-CVS or Arch (they're both
very "shallow" and have a unix-simplicity feel to them), but don't really
care either way when it comes down to it.

The problem is not whether we should switch, but when will we be able to.
The "support" issues I pointed out need to be resolved
first, including tranfering the history info from CVS to the new system
(it doesn't cut it to say "oh but you don't need it").

So when something like PCL-CVS exists, when Perspective provides the
same kind of functionality as ViewCVS (including .../foo/bar?rev=HEAD
links to post on newsgroups: I couldn't figure out how to do that),
when RPM packages are available everywhere, and when cvs2arch exists
and works (at least on the main branch), come back to bug me and I'll
be much more receptive to the idea, for sure.


	Stefan

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

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 2235 bytes --]

On Mon, Jun 09, 2003 at 09:47:00PM +0200, Juanma Barranquero wrote:
>Being from Barcelona and having had my home less than a kilometer away
>from it for years, I can *assure* you modern technology is used in its
>construction ("modern" for each succesive epoch) :)

Modern technology certainly is being used today, because Barcelonans are
smart.  Didn't they finish Sagrada Familia in time for the Olympics?  I
didn't realize it was a work in progress.

>> 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
>
>from which can be inferred that you're saying that significant
>contributions cannot be made without CVS write access. And that's Simply
>Not So.

No.  This is about personal write access, the ability to commit someone
elses source to your own private repository, without losing any history.
With arch, you can pull down the source, then "commit" it locally.  You
therefore have "write access", without having to be given write access
to the main tree.  You still retain full access to your new personal
trees "history", even though it is in another repository.

Try that with CVS.  It isn't trivial, easy, or natural.

>No. These are other, different concerns which with I can symphatize
>enough. As I've said, I'd vote for a switch to subversion Right Now if
>it were ready for prime time.

Subversion has design problems that it is unlikely to solve without
a radical rewrite.  Arch already solved these problems a year ago.

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Alex Schroeder]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> I understand that branches cause pain amongst the Emacs developers.

But will the pain go away when a new tool is used?  Perhaps the pain
is due to little testing, complex interaction between differing
patches on the various trees, complex sweeping changes to lots of
files introducing numerous bugs, interacting with each other...  So
basically a lot of pain is inherent in the problem we are facing:
Building complex software with few developers.  A different tool isn't
going to change that.  It is still complex software, and we are still
few developers.

That's why I'm against switching from CVS to something else at the
moment.  I don't feel like we're suffering much pain due to *CVS*.

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

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

[Robert Anderson]

On Mon, 2003-06-09 at 08:00, Juanma Barranquero wrote:
> 
> On 09 Jun 2003 07:37:24 -0700
> Robert Anderson <rwa@alumni.princeton.edu> wrote:
> 
> > Sure, and people could contribute if you read them the source over the
> > phone as well.  That's all they would "need."  Would you contribute if
> > that's all the facility you had?
> 
> I did (not the phone, the read-only access). Many people *do*, as I've
> said. I know, I end commiting quite a few of these patches.

With all due respect: duh.

> And forgive me, but the "phone line" example is a bit ridiculous.
> Read-only access to CVS repositories is tried and true.

So was hand-crank starter, or the ice box with daily ice delivery.

>It's not perfect, but is not *that* bad.

I find it unusable, but not mainly for that reason.

> arch, subversion, even BitKeeper if it was free, would perhaps be better
> than CVS; I'm not arguing against that. Just that CVS and read-only
> access aren't as great deterrents as you make it sound.

Care to show me the controlled experiment to demonstrate that? 
Otherwise, you are simply guessing.

 Just take a look
> at the very big and successful projects whose source control system is
> CVS.

Sorry, but this is an inane line of reasoning IMO.  I could equally
point out _massively many_ failed projects using CVS.  So what?

> Anyway, if I had to vote, I'd chose to wait for subversion.

That's because you don't understand either system, IMO.

> > It's not optimal, and neither is
> > working in an non source controlled environment for developing
> > substantial contributions.
> 
> No, it's not optimal, and certainly I don't remember having said it was.
> But even now there are people who does big contributions (I mean, not
> tiny patches of 5-10 lines, but changes of hundreds or thousands of
> lines) and who do not have write access nor (seem to) want it.

Sure, and monks used to scribe Bibles by hand and spread them around the
world.  I guess the printing press was never really needed.

Anyway: enough of the "CVS is good enough" thread for me.

Bob

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

[Kai Großjohann]

Alex Schroeder <alex@gnu.org> writes:

> kai.grossjohann@gmx.net (Kai Großjohann) writes:
>
>> I understand that branches cause pain amongst the Emacs developers.
>
> But will the pain go away when a new tool is used?  

Maybe not all of the pain.  But alleviating some of the pain is
already a good thing, isn't it?
-- 
This line is not blank.

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

[Juanma Barranquero]

On 09 Jun 2003 18:22:26 -0700
Robert Anderson <rwa@alumni.princeton.edu> wrote:

> That's because you don't understand either system, IMO.

Yeah, yeah, yeah. Pretty convincing.

                                                                Juanma

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

[Juanma Barranquero]

On Mon, 9 Jun 2003 22:11:49 +0200 
Jonathan Walther <krooger@debian.org> wrote:

> Didn't they finish Sagrada Familia in time for the Olympics?

No.

> I didn't realize it was a work in progress.

Yes, it is a work in progress, and will be for a long time. Most
optimistic estimation puts it at about 2100. Money, not technology, is
the limiting factor, of course. Barcelona does not pay the Sagrada
Familia work; individual contributions do.

> Try that with CVS.  It isn't trivial, easy, or natural.

I don't doubt it. I'm just saying that all these things, wonderful as
they are, don't imply that you can not do development well with CVS. You
can. Lotsa people can.

> Subversion has design problems that it is unlikely to solve without
> a radical rewrite.  Arch already solved these problems a year ago.

Yeah, but you know what? What I like more from subversion is that it
isn't radical, it "doesn't go far enough". It is (or tries to be) just
"a better CVS". A better CVS is fine by me.

                                                                Juanma

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

[Miles Bader]

On Tue, Jun 10, 2003 at 09:14:44AM +0200, Juanma Barranquero wrote:
> Yeah, but you know what? What I like more from subversion is that it
> isn't radical, it "doesn't go far enough". It is (or tries to be) just
> "a better CVS". A better CVS is fine by me.

Well actually even though I don't think it's the time to switch, arch seems
pretty cool, and when it _does_ come time to change someday, I think it's a
real contender.  Arch has an appealingly tool-oriented approach, and uses
`understandable' data representations, unlike subversion which seems to be
more of a `big binary blob' design...

I did find an interesting thread on arch on the OpenBSD mailing list, BTW,
where Tom Lord does a pretty good job of answering some skeptical questions;
a google search should turn it up...

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

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

[Juanma Barranquero]

On Tue, 10 Jun 2003 08:59:29 -0400
Miles Bader <miles@gnu.org> wrote:

> Arch has an appealingly tool-oriented approach, and uses
> `understandable' data representations, unlike subversion which seems to be
> more of a `big binary blob' design...

I'm not arguing for or against any such tool now, but the "big binary
blob" is not a problem per se, if well documented.

> I did find an interesting thread on arch on the OpenBSD mailing list, BTW,
> where Tom Lord does a pretty good job of answering some skeptical questions;
> a google search should turn it up...

There was a long thread about arch on the GCC list months ago, and Tom
Lord did talk at length about arch's strengths and weaknesses.


                                                                Juanma

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

[Robert Anderson]

On Mon, 2003-06-09 at 23:53, Juanma Barranquero wrote:
> 
> On 09 Jun 2003 18:22:26 -0700
> Robert Anderson <rwa@alumni.princeton.edu> wrote:
> 
> > That's because you don't understand either system, IMO.
> 
> Yeah, yeah, yeah. Pretty convincing.
> 
>                                                                 Juanma

If you'd like to discuss it, this is not the place for it.  I invite you
to arch-users for lack of a better forum.

Bob

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

[Stefan Monnier]

> > Arch has an appealingly tool-oriented approach, and uses
> > `understandable' data representations, unlike subversion which seems to be
> > more of a `big binary blob' design...
> 
> I'm not arguing for or against any such tool now, but the "big binary
> blob" is not a problem per se, if well documented.

It is a problem because you can't look inside with the usual tools,
so you end up locked with a specific set of tools and you have to
use them to get anything done.  And when there's a bug, it can end
up pretty disastrous (basically, the big-binary-blob implements
something like a file-system, so a bug is like a bug in your kernel
that can trash your entire file system).

It's not unbearable, but saying that "Subversion is just a better CVS"
is just silly.  The implementation of Subversion is far more radical than
the one of OpenCM, Arch, and Meta-CVS (which is why it's taking so long,
BTW, especially compared to single-man efforts such as Arch or
Meta-CVS).


	Stefan

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

[Robert Anderson]

On Tue, 2003-06-10 at 07:05, Juanma Barranquero wrote:
> 
> On Tue, 10 Jun 2003 08:59:29 -0400
> Miles Bader <miles@gnu.org> wrote:
> 
> > Arch has an appealingly tool-oriented approach, and uses
> > `understandable' data representations, unlike subversion which seems to be
> > more of a `big binary blob' design...
> 
> I'm not arguing for or against any such tool now, but the "big binary
> blob" is not a problem per se, if well documented.

While I agree with Miles, the really weighty pragmatic arguments don't
have anything do with design, IMO, but rather functionality.

> 
> > I did find an interesting thread on arch on the OpenBSD mailing list, BTW,
> > where Tom Lord does a pretty good job of answering some skeptical questions;
> > a google search should turn it up...
> 
> There was a long thread about arch on the GCC list months ago, and Tom
> Lord did talk at length about arch's strengths and weaknesses.
> 
> 
>                                                                 Juanma

The gulf between the two systems can be characterized with one word:
distribution.  That's not all, of course, but it's enough, and a gap
that is, IMO, _very_ unlikely to be closed in a time frame of a few
years, if ever.

Bob

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

[Juanma Barranquero]

On Tue, 10 Jun 2003 10:37:59 -0400
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> It is a problem because you can't look inside with the usual tools,
> so you end up locked with a specific set of tools and you have to
> use them to get anything done.

Yes, but that's ameliorated if the format is well documented. And, I'd
really hope if we do switch to another system, it'll be one more stable
than CVS :)

> And when there's a bug, it can end
> up pretty disastrous (basically, the big-binary-blob implements
> something like a file-system, so a bug is like a bug in your kernel
> that can trash your entire file system).

Sure. Backups are always needed.

> It's not unbearable, but saying that "Subversion is just a better CVS"
> is just silly.  The implementation of Subversion is far more radical than
> the one of OpenCM, Arch, and Meta-CVS (which is why it's taking so long,
> BTW, especially compared to single-man efforts such as Arch or
> Meta-CVS).

I know. But I'm not talking about implementation. Nowhere in this thread
I've done so. Subversion is a better CVS, from the user's POV. I'd like
to use a program with a similar mindset, user-wise, than CVS. BitKeeper,
for what I've heard, is vastly different, and I think arch too.

                                                                Juanma

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

[Stefan Monnier]

> I know. But I'm not talking about implementation. Nowhere in this thread
> I've done so. Subversion is a better CVS, from the user's POV. I'd like
> to use a program with a similar mindset, user-wise, than CVS. BitKeeper,
> for what I've heard, is vastly different, and I think arch too.

Hmm... for me, what makes CVS what it is, is that it's (add salt
throughout) easy to setup, easy to administer, lightweight, in
the sense that when something goes wrong, you don't need to learn
much about the in-repository format because it's basically obvious,
so you can fix things fairly easily with the usual tools.
I.e. you get to reuse the knowledge you've acquired while using
all those other unix tools.

The "mindset" of the user interface is much less significant,
from my point of view.  I also think it tends to be over-emphasized
in all those tools where they use new terms and warn you "this
is a whole new concept" whereas in the end it's just very much
all the same: edit, update, merge, diff, commit.

Sure things like tags and branches might work differently, but
note that Subversion is radically different from CVS in this respect
as well ;-)


	Stefan

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

[Miles Bader]

On Tue, Jun 10, 2003 at 04:55:44PM +0200, Juanma Barranquero wrote:
> > It is a problem because you can't look inside with the usual tools,
> > so you end up locked with a specific set of tools and you have to
> > use them to get anything done.
> 
> Yes, but that's ameliorated if the format is well documented.

Well, no it's not.  If writing tools to get at the data is hard or risky then
things still suck, no matter how well documented the format is.

For many users, of course, it's the same either way, but one of the big
attractions of CVS was exactly that what it does is quite understandable, and
when all else failed, you could use emacs to edit the repository...

> > And when there's a bug, it can end up pretty disastrous (basically, the
> > big-binary-blob implements something like a file-system, so a bug is like
> > a bug in your kernel that can trash your entire file system).
> 
> Sure. Backups are always needed.

Um, that's not exactly a comforting answer...

I'd rather have things _not get trashed_!

Failing that, I'd like the damage to be limited, and recoverable, and the
more I can do this without using special tools, the better (special tools are
great when they work of course, but ...).

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

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

[Richard Stallman]

    Yes, it is a work in progress, and will be for a long time. Most
    optimistic estimation puts it at about 2100.

They told me it was expected to be finished in a couple of decades.
I saw lots of work going on, last January.

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

[Juanma Barranquero]

On Tue, 10 Jun 2003 11:03:14 -0400
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> when something goes wrong, you don't need to learn
> much about the in-repository format because it's basically obvious,
> so you can fix things fairly easily with the usual tools.
> I.e. you get to reuse the knowledge you've acquired while using
> all those other unix tools.

I've got the feeling that CVSROOT/* and friends are "basically obvious"
only to people with some sort of Unix background. But as you know, CVS
can be (and is) used from other, "friendlier" environments by people to
whom all these files would be black magic.

> I also think it tends to be over-emphasized
> in all those tools where they use new terms and warn you "this
> is a whole new concept" whereas in the end it's just very much
> all the same: edit, update, merge, diff, commit.

Yeah, I agree with that. Still, some of them insist in things like
decentralization, etc. I've got nothing against a centralized repository,
on the contrary :)

> Sure things like tags and branches might work differently, but
> note that Subversion is radically different from CVS in this respect
> as well ;-)

Fair enough :)

                                                                Juanma

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

[Juanma Barranquero]

On Tue, 10 Jun 2003 16:16:17 -0400
Miles Bader <miles@gnu.org> wrote:

> Well, no it's not.  If writing tools to get at the data is hard or risky then
> things still suck, no matter how well documented the format is.

Yeah, sure. But "binary repository" does not necessarily imply "getting
the data is hard or risky".

> For many users, of course, it's the same either way, but one of the big
> attractions of CVS was exactly that what it does is quite understandable, and
> when all else failed, you could use emacs to edit the repository...

As I've said in another message, what CVS does is not that
understandable for people with a non-Unix background (I think).

> Um, that's not exactly a comforting answer...
> 
> I'd rather have things _not get trashed_!

Yeah, but again: binary does not imply more fragile. What if you save
things compressed, but do two or three copies? I mean, if I were
implementing a "binary virtual filesystem" for source control, I'd do my
best to make the thing reliable against catastrophes... I'd expect the
same from actual source control developers.

Database systems like Oracle do save their data in binary, proprietary
formats, and in my experience you don't lose data often with Oracle.
Perhaps I've been fortunate ;)

> Failing that, I'd like the damage to be limited, and recoverable, and the
> more I can do this without using special tools, the better (special tools are
> great when they work of course, but ...).

I agree. Of course I'd rather have the data in clear text, easy to
access, than in binary formats. But if binary is going to buy me other
commodities, I'm willing to trust the developers (after a few
months/years of testing, of course ;)

All in all, I have a slight preference for Subversion, but any system
that works reliably, it's faster than CVS and improves on its worst
"features" is fine by me (when the time is ripe).

                                                                Juanma

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

[Juanma Barranquero]

On Tue, 10 Jun 2003 20:25:08 -0400
Richard Stallman <rms@gnu.org> wrote:

> They told me it was expected to be finished in a couple of decades.
> I saw lots of work going on, last January.

Yeah, there's always a lot of work going.

Still, a couple decades seems way too optimistic. I've seen this thing
grow from 1982 to this day, more or less, and there's been not that much
development. And every time a new fragment is proposed, controversy
arises about the "true master plan" of Gaudí (from which no real plans
remain for the rest of the cathedral) and words like "traitor" and
"horror" and "modern" (derisive :) are heard.

                                                                Juanma


P.S.: All that said, I think the Sagrada Familia is the most beautiful
building in the world. What I felt the first time I was in front of it...
I cannot describe it; like a deep, wonderful, sad, joyful heartache that
left me speechless. The only other time I've felt so was the first time
I saw the Guanabara Bay from the Pão de Açucar.

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

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 1658 bytes --]

On Wed, Jun 11, 2003 at 09:19:55AM +0200, Juanma Barranquero wrote:
>Still, a couple decades seems way too optimistic. I've seen this thing
>grow from 1982 to this day, more or less, and there's been not that much
>development. And every time a new fragment is proposed, controversy
>arises about the "true master plan" of Gaudi (from which no real plans
>remain for the rest of the cathedral) and words like "traitor" and
>"horror" and "modern" (derisive :) are heard.

This is how a real cathedral is built to last the ages; the product of
many different groups collaborating, arguing, and cooperating with each
other.  It truly embodies the spirit of the community that built it.  No
matter what ones religion or lack thereof, a great cathedral in ones
town is something to be proud of.

Oh, and it's not abnormal for a cathedral to take 200 years to finish.
Being built by community members is also part of the tradition. You can
have your open source bazaar; I'll take a free software cathedral
any day. :-)

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Stefan Monnier]

> I've got the feeling that CVSROOT/* and friends are "basically obvious"
> only to people with some sort of Unix background. But as you know, CVS

I don't think so.  I think they're only non-obvious to people for whom
*any* repository structure would be non-obvious.  After all, they're
just plain text and have very few interdependencies.

You copy the repository with rsync just fine (it might end up being
in a somewhat inconsistent state where some commits are missing,
but it will work just fine), whereas with something Subversion there's
a particular protocol to follow.  Of course, it has its own advantages.

> Yeah, I agree with that. Still, some of them insist in things like
> decentralization, etc. I've got nothing against a centralized repository,
> on the contrary :)

Arch does not impose any decentralization whatsoever.  All it does is
that it allows decentralization if you want it, and since it's something
that other systems can't do (and it's really neat when you need it),
of course they talk a lot about it.  But it's like CVS going on and
on about remote repositories: that doesn't mean "I'll use RCS because
I want my repository to be local".


	Stefan

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

[Juanma Barranquero]

On Wed, 11 Jun 2003 10:11:40 -0400
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> I don't think so.  I think they're only non-obvious to people for whom
> *any* repository structure would be non-obvious.  After all, they're
> just plain text and have very few interdependencies.

I think they're "obvious" in the sense that cutting and pasting your
code from then (in the case of catastrophic failure) is posible.
Non-obvious in the sense that, after that crash, is not easy to modify
the CVS files to get a working repository again. At least, not to people
who's not spent a time delving into the documentation and/or the CVSROOT
files themselves.

> Arch does not impose any decentralization whatsoever.  All it does is
> that it allows decentralization if you want it, and since it's something
> that other systems can't do (and it's really neat when you need it),
> of course they talk a lot about it.

I was thinking more of BitKeeper (after reading long arguments from
Linus et al). My understanding is that BitKeeper imposes it, in the
sense that with BK there's no central repository and checked out source
trees, but more like multiple repositories which are synchronized every
now and then. But I can be wrong, I've not read BK documentation.

> But it's like CVS going on and
> on about remote repositories: that doesn't mean "I'll use RCS because
> I want my repository to be local".

Sure. I didn't want to imply that. Sorry for the misunderstanding.

                                                                Juanma