all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Yavor Doganov <yavor@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: dVCS vs. CVS
Date: Tue, 08 Jan 2008 11:28:13 +0200	[thread overview]
Message-ID: <87myrg7jki.GNU's_Not_Unix!%yavor@gnu.org> (raw)
In-Reply-To: <87wsqlhbcp.fsf@member.fsf.org>

Please don't misunderstand me -- I'm not defending CVS and do not
dispute the many advantages of dVCS.  I am just disappointed that
nearly all projects ignore the drawbacks they bring in to
non-technical people.

Tassilo Horn wrote:
> 
> I disagree.  With CVS the basic workcycle for non-members looks like
[...]
> With git (or any other dVCS) it'd be something like

It would be easier if it was one of them.  I am doomed to use all of
them (and I really mean all).  Often translators have to work on a
release branch, or sometimes the developers prefer to receive patches
in the natural way, specific to the VCS they use.  It takes time to
learn even basic (d)VCS operations, needless to say that it is easy to
forget the command you need at the moment.

I am quite certain that even developers can experience such
frustration, for example if you actively participate in three
different projects that use Git, Arch and Monotone.  "Cheap branching
and painless merging" then is not so cheap and painless, because you
might often need to consult the documentation for many things.

GNOME rejected migration from Subversion to dVCS precisely because it
would make translators' life much harder (some old-fashioned hackers
objected too.)

Anyway, as I said both points are probably moot.  Emacs is not
translatable for the time being and developers write the documentation
themselves.

> > Autoconf, Automake, m4, Gnulib 

> I guess that's not a good comparison, because those are pretty boring
> projects for most people.

Maybe you're right.  We'll see.

David Kastrup wrote:
> 
> [...] a version control system that allows you to mess up in private
> rather than clobbering a public repository is certainly [...]

It is also very easy to transfer the local mess (or undesired history)
to the public repository (this happened for dpkg, IIRC, and one other
project I don't remember).

The assumptions you make are valid from the standpoint of a (skilled)
developer, but to understand the problem you have to look from a
drastically different point of view, without prejudice.

  parent reply	other threads:[~2008-01-08  9:28 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 [this message]
2008-01-08 12:59       ` Miles Bader
2008-01-07 16:05   ` David Kastrup
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

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

  git send-email \
    --in-reply-to='87myrg7jki.GNU'\''s_Not_Unix'\!'%yavor@gnu.org' \
    --to=yavor@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.