Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[Eric S. Raymond]

From: Jason Rumney <jasonr@gnu.org>
> Subject: Re: Policy issue in the VC manual -- recommending CVS?!?
> To: "Eric S. Raymond" <esr@snark.thyrsus.com>
> Cc: emacs-devel@gnu.org
> Message-ID: <470D40AA.6020400@gnu.org>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Eric S. Raymond wrote:
> > Recommending GNU arch is dubious considering Arch's poorly-maintained
> > and poorly-documented state.  If I'm not mistaken, Arch has been
> > effectively moribund since about 2003.
> >   
> 
> I think you're mistaken. Savannah lists the last release as July last year.

So it's only been over a year since the last point release.  I'm not 
hugely reassured.
 
> > Recommending CVS is well beyond dubious into outright ridiculous.
> 
> Like it or not, CVS is stable, and widely used. Its "problems" are
> widely exaggerated by adherents to the latest wave of version control
> religions.

Er.  I've been using VCSes since the days when SCCS was the only one
in existence.  The fact that I still cheerfully use RCS, the second
one ever built, makes me pretty bulletproof against charges of
version-control faddism.  But file-oriented VCSes just plain suck
for distributed projects, and there's no way to make them not suck.

> > No recommendations at all would be better than these.  Who decides
> > what the manual recommends?  If it's "the last person to care", I'm
> > going to nuke these in a nanosecond.
> Arch is part of GNU

Please tell me you're not implying that we should recommend an inferior
GPLed tool over a superior one just because the inferior is distributed
from an FSF server.  That would be taking political jaundice to an
absurd extreme.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[Manoj Srivastava]

On Wed, 10 Oct 2007 17:44:19 -0400, Eric S Raymond <esr@thyrsus.com> said: 

> From: Jason Rumney <jasonr@gnu.org>
>> Subject: Re: Policy issue in the VC manual -- recommending CVS?!?
>> To: "Eric S. Raymond" <esr@snark.thyrsus.com>
>> Cc: emacs-devel@gnu.org
>> Message-ID: <470D40AA.6020400@gnu.org> Content-Type: text/plain;
>> charset=ISO-8859-1
>> 
>> Eric S. Raymond wrote:
>> > Recommending GNU arch is dubious considering Arch's
>> > poorly-maintained and poorly-documented state.  If I'm not
>> > mistaken, Arch has been effectively moribund since about 2003.
>> >   
>> 
>> I think you're mistaken. Savannah lists the last release as July last
>> year.

> So it's only been over a year since the last point release.  I'm not
> hugely reassured.

        I can assure you that the tool is functional, and is in
 production use in a number of projects. 

>> > Recommending CVS is well beyond dubious into outright ridiculous.
>> 
>> Like it or not, CVS is stable, and widely used. Its "problems" are
>> widely exaggerated by adherents to the latest wave of version control
>> religions.

> Er.  I've been using VCSes since the days when SCCS was the only one
> in existence.  The fact that I still cheerfully use RCS, the second
> one ever built, makes me pretty bulletproof against charges of
> version-control faddism.  But file-oriented VCSes just plain suck for
> distributed projects, and there's no way to make them not suck.

>> > No recommendations at all would be better than these.  Who decides
>> > what the manual recommends?  If it's "the last person to care", I'm
>> > going to nuke these in a nanosecond.
>> Arch is part of GNU

> Please tell me you're not implying that we should recommend an
> inferior GPLed tool over a superior one just because the inferior is
> distributed from an FSF server.  That would be taking political
> jaundice to an absurd extreme.

        I think you first have to make your case that arch is
 inferior. It does not change a whole lot, but what we have works just
 fine.  Over the last year I have twice evaluate bzr and git, and found
 that they do not support the feature set of arch that I have come to
 rely upon -- so in my view, at least, bzr and git are the inferior
 products. YMMV.

        manoj
-- 
God isn't dead, he just couldn't find a parking place.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[Jason Rumney]

Eric S. Raymond wrote:
> So it's only been over a year since the last point release.  I'm not 
> hugely reassured.
>   

I'm not sure why stability is seen as such a bad thing these days,
especially for a revision control tool.

Re: Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[Eric S. Raymond]

Jason Rumney <jasonr@gnu.org>:
> Eric S. Raymond wrote:
> > So it's only been over a year since the last point release.  I'm not 
> > hugely reassured.
> 
> I'm not sure why stability is seen as such a bad thing these days,
> especially for a revision control tool.

Stability is good.  Signs of life and responsiveness from the dev team
are, however, just as important.  I want to have reasonable confidence
that someone is alive to deal with bug reports.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > Stability is good.  Signs of life and responsiveness from the dev team
 > are, however, just as important.  I want to have reasonable confidence
 > that someone is alive to deal with bug reports.

It's not bug reports that are the issue in a recommendation like this
one; it's usability.  Arch is stable, and works well as designed.  The
issue I think is important is that Arch pioneered the "porcelain
vs. plumbing" distinction that git has so felicitously described; Arch
proper is plumbing, unlike what you (incorrectly) class as "more
modern" derivatives like bazaar and bzr.  They're not "more modern",
they're simply integrated and to some extent simplified (Tom would say
"dumbed-down") porcelains.  (Plumbing may be optimized, as well, which
is a huge issue with darcs and something of an issue with Arch.)

Arch has proved itself quite amenable to Emacs-based porcelains like
xetla, while still providing the raw power of Arch itself.  (Although
I haven't experienced Arch as more powerful than git; I'm curious what
use cases Manoj has in mind that Arch handles well while git does not.)

Nonetheless, I would not recommend Arch as a distributed VC to a
project looking for a VC unless the developers are experienced with
and like Arch (in which case a recommendation in vc.texi is
gratuitous, at least at *the* time of writing ;-).  As you probably
perceive, I consider the porcelain/plumbing distinction as elegant and
useful, but all active VC product communities that I know well enough
to consider for my own projects (bzr, hg, git, darcs) are very firmly
in the "porcelain-attached" camp.  I suppose that there's a reason
for that; my guess is that it gives a much smoother startup, and a
confused early history can cause a lot of pain later.

I don't have time to review the texi in detail, but I would suggest
recommending Subversion for traditional centralized organization and
as a robust vehicle for timely delivery of sanctioned versioned source
code, the foursome above (possibly adding Monotone about which I know
nothing) for general distributed use, and mentioning the existence of
GNU Arch (which after all is a GNU project and does have some special
features, not to mention substantial historic interest).  Then point
to one or more of the excellent comparison pages out on the web, or to
Wikipedia which though of uneven quality is likely to be updated
reasonably often.

HTH

Re: Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[Stefan Monnier]

>> > Recommending GNU arch is dubious considering Arch's poorly-maintained
>> > and poorly-documented state.  If I'm not mistaken, Arch has been
>> > effectively moribund since about 2003.

Let's see what we currently support:

  (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch MCVS)

[with DaRCS being hopefully added soon]
Of those, when starting a new project, I wouldn't want to recommend any one
in particular: they all have their strength and weaknesses.  I don't think
it's our role to pimp one over another.  And given the fact that Emacs
provides no particular support to start a project under either of those VCS
anyway, I think we should simply punt on this issue.


        Stefan

Re: Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> Let's see what we currently support:
> 
>   (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch MCVS)
> 
> [with DaRCS being hopefully added soon]

I see a rudimentary Monotone back end in CVS, too.  Are you planning to
finish that?

> Of those, when starting a new project, I wouldn't want to recommend any one
> in particular: they all have their strength and weaknesses.  I don't think
> it's our role to pimp one over another.  And given the fact that Emacs
> provides no particular support to start a project under either of those VCS
> anyway, I think we should simply punt on this issue.

RMS said to drop it, so I had already removed the recommendations from
CVS head.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Manual policy (Re: Emacs-devel Digest, Vol 44, Issue 65)

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca>:
>> Let's see what we currently support:
>> 
>>   (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch MCVS)
>> 
>> [with DaRCS being hopefully added soon]
>
> I see a rudimentary Monotone back end in CVS, too.  Are you planning to
> finish that?

Mtn?

-- 
David Kastrup