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