unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: dVCS vs. CVS
Date: Mon, 07 Jan 2008 17:05:11 +0100	[thread overview]
Message-ID: <857iilbozs.fsf@lola.goethe.zz> (raw)
In-Reply-To: <87prwd7j8l.GNU's_Not_Unix!%yavor@gnu.org> (Yavor Doganov's message of "Mon, 07 Jan 2008 17:23:06 +0200")

Yavor Doganov <yavor@gnu.org> writes:

> Bastien wrote:
>> 
>> The risk of switching to a dVCS is not one of loosing
>> functionnalities, but one of loosing those developers who don't want
>> to learn a new tool (I don't think there are any here...?)
>
> Maybe there aren't, and probably what I am going to say does not
> relate at all to the Emacs project.  But there are two important
> things that were missed in that huge thread:
>
> Lifting the barrier -
>
> dVCS (and the fact that there are many of them) are a nightmare for
> contributors who are not programmers, like translators and
> documentation writers.

Sorry, but that's nonsense.  The fact that there many of them does not
cause any headaches except for the one picking out one, and a version
control system that allows you to mess up in private rather than
clobbering a public repository is certainly much less of an impediment
for learning then one where organizing any contributions of you with the
help of a VCS requires you to have write access to the central canonical
repository used and needed by everybody.

Many non-technical persons have little qualms messing up their own
system completely and starting over when getting acquainted with
software.  But they better be less non-chalant about messing up a
central repository.

> A dVCS is a sophisticated tool and a complicated concept that such
> people do not understand, or at least they do after substantial
> investment of time and sweat.

But they don't need to understand the distributed aspect.  They can just
work with their own repository without ever getting commit access to the
central one, and create patches and offer them.  When those get accepted
upstream, their repository will notice when it is next updated and drop
the duplication.

They can do much more useful work without being a risk.

> Autoconf, Automake, m4, Gnulib and other projects switched to Git some
> time ago.  One would expect that there will be an avalanche of new
> contributors who were not volunteering only because they needed a
> modern VCS to go ahead.  False assumption -- pretty much the same
> people hack on these projects after the switch.

Sure.  The question is whether they are more effective in that manner.

Linus Torvalds averages something in the order of hundreds of daily
patch sets for reviewing, applying, handling in the Linux kernel.  He
would not be doing that using CVS.  And others would be much harder
pressed to test their individual kernel versions and do development on
it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  parent reply	other threads:[~2008-01-07 16:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-06 14:01 dVCS vs. CVS Bastien
2008-01-07 15:23 ` Yavor Doganov
2008-01-07 16:03   ` Tassilo Horn
2008-01-07 21:00     ` Alan Mackenzie
2008-01-07 22:45       ` Tassilo Horn
2008-01-08  2:46         ` Michael Olson
2008-01-08  9:28     ` Yavor Doganov
2008-01-08 12:59       ` Miles Bader
2008-01-07 16:05   ` David Kastrup [this message]
2008-01-07 21:52     ` Bastien
2008-01-07 21:59     ` Stephen J. Turnbull
2008-01-07 22:19       ` David Kastrup
2008-01-08  8:57         ` Stephen J. Turnbull
2008-01-09 11:37           ` Richard Stallman
2008-01-07 22:33       ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=857iilbozs.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).