emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dVCS vs. CVS


From: Yavor Doganov
Subject: Re: dVCS vs. CVS
Date: Tue, 08 Jan 2008 11:28:13 +0200
User-agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj┼Ź) APEL/10.7 Emacs/22.1 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]