dVCS vs. CVS

dVCS vs. CVS

[Bastien]

The comparison between CVS and dVCS is necessarily limited because it's
hard to compared a decentralized system with a centralized one.

But let me simply point out this obvious fact: with a dVCS, you can do
whatever you would do with CVS -- and *more*.  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...?)

Another point: it has been said in this thread that, in dVCS, "The
'current development version' is a social, not a technical concept."
This is the most important fact about dVCS in general.  But be aware
that this might be misunderstood: it doesn't mean you lose control over
which developpement version is to be considered the "official" one (by
not technically defining it), it means that you make clear the official
developpement version is so by a social convention (not de facto, via
technical constraints.) 

Concretely, it means that people will work with the GNU dVCS repository
(wherever this would live) *because* they know this is the official one,
not because this is the only one.

I think this way of defining the current developpement version fits
perfectly with the role of conventions in Emacs development.

-- 
Bastien

Re: dVCS vs. CVS

[Yavor Doganov]

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

Not a silver bullet -

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.

Re: dVCS vs. CVS

[Tassilo Horn]

Yavor Doganov <yavor@gnu.org> writes:

Hi Yavor,

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

I disagree.  With CVS the basic workcycle for non-members looks like

  cvs up
  <edit>
  cvs up # To check there're no conflicts
  cvs diff > foo.patch
  <email patch to emacs-devel>

With git (or any other dVCS) it'd be something like

  git-pull # pull from origin
  <edit>
  git-pull
  git-commit -m "Foo bar"
  git-format-patch origin
  <email patch to emacs-devel>

So basically the only difference is that you have to commit to your
local repository.  As long as you don't use more advanced functions of
the dVCS, there's nothing more complicated.

> Not a silver bullet -
>
> 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.

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

Another project that switched from CVS to git recently is stumpwm, and
this project now has a hundfull of contributors now instead of only one.

Bye,
Tassilo

Re: dVCS vs. CVS

[Alan Mackenzie]

On Mon, Jan 07, 2008 at 05:03:18PM +0100, Tassilo Horn wrote:
> > 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.  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.

Also, a dVCS is much easier to understand for people who've already used
CVS (or the like).

> I disagree.  With CVS the basic workcycle for non-members looks like

>   cvs up
>   <edit>
>   cvs up # To check there're no conflicts
>   cvs diff > foo.patch
>   <email patch to emacs-devel>

> With git (or any other dVCS) it'd be something like

>   git-pull # pull from origin
>   <edit>
>   git-pull
>   git-commit -m "Foo bar"
>   git-format-patch origin
>   <email patch to emacs-devel>

> So basically the only difference is that you have to commit to your
> local repository.  As long as you don't use more advanced functions of
> the dVCS, there's nothing more complicated.

Sorry, but no.  What makes it complicated are all the other things that
you don't want to use.  The things that are there, but you are forced to
ignore.  The things that are going to trip you up, sooner or later, when
somebody else does something which forces you to pay attention.  The
things that make it difficult to build an internal mental model.  Or when
you unfortunately mis-type a command and put your own files into a wierd
state.

I hate it when people do that to me - for example, making me use some
ghastly GUI interface, telling how easy everything is, and demonstrating
by clicking on one of many, many tiny little obscure icons with "that's
all you need to do, what's difficult about that?".  What's difficult is
ignoring the other 73 obscure little icons, and having to find the "easy"
command 3 levels of menu down leading to a 2 nested tab boxes and a
partridge in a pear tree.

It's a bit like saying Emacs is simple, because you can use it "just
like" a very basic text editor.

Also, a dVCS's documentation is more complicated.  Unless, of course, its
writers write a special cut down version for "unsophisticated" users -
Something they're hardly likely to, since they will want to encourage
people to use it "properly".

> > Not a silver bullet -

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

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

So's Emacs.  ;-)

> Another project that switched from CVS to git recently is stumpwm, and
> this project now has a hundfull of contributors now instead of only one.

I can't honestly imagine that the VCS system in use is that critical a
factor in attracting most new contributors.  If I were joining Emacs
today, CVS wouldn't put me off, neither would git or mercurial or
whatever.  But for writers rather than programmers, a dVCS might well
push their tenacity to the limit.

> Bye,
> Tassilo

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: dVCS vs. CVS

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

>> So basically the only difference is that you have to commit to your
>> local repository.  As long as you don't use more advanced functions
>> of the dVCS, there's nothing more complicated.
>
> Sorry, but no.  What makes it complicated are all the other things
> that you don't want to use.  The things that are there, but you are
> forced to ignore.

You can shoot yourself in the foot with CVS, too.  But it's easy to give
non-programmers a recipe how they can work with a dVCS as well as it is
possible with CVS now.

> It's a bit like saying Emacs is simple, because you can use it "just
> like" a very basic text editor.

But it's not much different than with CVS today.  You can do much more
with it than only the usual up, edit, ci/diff cycle.

> Also, a dVCS's documentation is more complicated.  Unless, of course,
> its writers write a special cut down version for "unsophisticated"
> users - Something they're hardly likely to, since they will want to
> encourage people to use it "properly".

At least git has a short "Everyday git" tutorial that explains the few
commands each role may use.  If the dVCS we choose has no such
documentation, it won't be hard to write one ourselves.

>> > 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.
>
>> I guess that's not a good comparison, because those are pretty boring
>> projects for most people.
>
> So's Emacs.  ;-)

Haha.

But generally I'd say end-user applications attract more voluntary
programmers than libs and build tools.

>> Another project that switched from CVS to git recently is stumpwm,
>> and this project now has a hundfull of contributors now instead of
>> only one.
>
> I can't honestly imagine that the VCS system in use is that critical a
> factor in attracting most new contributors.

Surely, it's not critical, but it's convenient.  Not only for new
contributors, but for every programmer.

Take me as an example.  I have some items on my todo list, but since my
time is quite limited, I don't even start to implement them, since when
I do so I cannot commit till it's finished.  With a dVCS I would create
a new local branch for a task and work on it when I want.  I could
switch back to the main branch to fix a bug or make a quick change
whenever I want.

(Sure, I can checkout emacs many times to simulate multiple local
branches, but that has other drawbacks.)

Bye,
Tassilo

Re: dVCS vs. CVS

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 1363 bytes --]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
> Hi Alan,
>
>>> So basically the only difference is that you have to commit to your
>>> local repository.  As long as you don't use more advanced functions
>>> of the dVCS, there's nothing more complicated.
>>
>> Sorry, but no.  What makes it complicated are all the other things
>> that you don't want to use.  The things that are there, but you are
>> forced to ignore.
>
> You can shoot yourself in the foot with CVS, too.  But it's easy to
> give non-programmers a recipe how they can work with a dVCS as well as
> it is possible with CVS now.

Even for programmers, a recipe for how to use the current dVCS is
useful.  Every one of the projects I maintain has its own quickstart
guide for how to use git, tailored to the location of the repository for
each project, and its active branches.

Here they are:

 - http://www.emacswiki.org/cgi-bin/wiki/ErcDevelopment
 - http://www.emacswiki.org/cgi-bin/wiki/MuseDevelopment
 - http://www.emacswiki.org/cgi-bin/wiki/PlannerDevelopment

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
          Programmer -- Hobbies: Lisp, HCoop          | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: dVCS vs. CVS

[Yavor Doganov]

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.

Re: dVCS vs. CVS

[Miles Bader]

Yavor Doganov <yavor@gnu.org> writes:
> 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.

Your description below makes it sounds like the (presumed) disadvantage
is not from dCVS per-se, but rather simply from _any_ change in tools.

It's true that a project probably shouldn't be changing the tools it
uses too often (that just confuses everybody), but I think change is
inevitable in the long run, and in the long run I'm not sure it makes
much difference whether it happens tuesday or thursday...

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: dVCS vs. CVS

[David Kastrup]

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

Re: dVCS vs. CVS

[Bastien]

David Kastrup <dak@gnu.org> writes:

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

Yes. This is precisely why a dVCS might help new people feel more
confident when submitting patches.  For now, the workflow is this:

1. find an issue
2. hack, fix it
3. check whether the code is correct
4. submit the patch to emacs-devel

Newcomers who wants to reach step 4 will have to go thru step 3 first,
and carefully review their code.  But when?  Right now?  A bit later,
when they feel more confident that they found the right solution to a
real problem?  I guess that in most cases, they will delay a bit before
sending anything.  And delaying means that they might loose track of the
change, or of the idea, or they will think it might have been magically
fixed in the meantime.

dVCS lets you work on your side without urging you to put your code
under public scrutiny.  You push when you're ready.  Others pull from
your repository when they think your code is okay.

-- 
Bastien

Re: dVCS vs. CVS

[Stephen J. Turnbull]

David Kastrup writes:

 > Yavor Doganov <yavor@gnu.org> writes:
 > 
 > > 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.

Please, David, don't overstate your case.  It's not "nonsense".  This
is an issue that has surfaced on Debian's I18N list.  It is one
motivation for web-based translation systems like Rosetta Stone.  The
problem is that nontechnical contributors tend to contribute to a lot
of projects ("dozens" is not unusual) simultaneously.  Eg, the
difference in semantics between "hg pull" (does not update the
workspace) and "git pull" (does update the workspace) is somewhat
confusing and can be very annoying to some users.

That said, I don't consider this a reason for any project not to
change its VCS, especially not from CVS to a dVCS.  It's simple enough
to insulate the nontechnical contributors from the changeover, though
it may require some creativity and effort.

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

This makes me laugh.  The autotools are such a crock (a crucially
important crock, but a horrible crock nonetheless) that it's amazing
they haven't suffered a dambreak and aren't gushing forth developers,
cackling insanely.  Maybe it's git that saved them.  (^^;;

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

No, but he did approximate it without any VCS at all.  And, AIUI, that
is where Richard is coming from.  Admittedly, without a dVCS, to do
what Richard does or what Linus used to do requires extreme talent as
well as discipline.  However, with discipline it is possible for any
developer to achieve fairly high productivity (explicit estimates in
this list have been running about 20-25% less than with the tool, very
small compared to the 10:1 differences commonly reported for
differentials across developers in both LOC and defect rate).

Now, I see no reason to believe that Emacs is lacking such
discipline.  The behavior of Richard, Eli, and Alan leads me to
believe, on the contrary, that there is a powerful discipline here.
If so, such a discipline is a more or less fixed investment, that
shows up in a reluctance to change workflow.  That reluctance is
well-justified!

But individual developer workflow does not *need* to change
immediately (viz. my last post), and in practice will change very
naturally, almost without friction, as even very conservative
developers start grabbing the new tools available to them.  Project
workflow probably *should* change somewhat, but the necessary changes
can and should be implemented and maintained by the dCVS advocates and
other volunteers.  Here's an example.

XEmacs, a project with a culture and developer mix similar to Emacs's,
recently (December 15) changed over from CVS to Mercurial for our
mainline.  Little has changed.  Semi-conservatives like myself (we
were using dVCSes privately but were reluctant to change the public
repo) have experienced an immediate modest productivity increase (in
terms of rate of pushing changesets, which is an appropriate measure
of productivity for "conservative" developers) for three reasons:

    - inordinate fear of pushing something broken has dramatically
      decreased, partly because the VCS is more robust, and partly
      because the initial push goes to a "bleeding edge" repo, and a
      gatekeeper moves it from there to the "testing" repo after a few
      days without blood (workflow discipline still matters, you see,
      but important parts of it can be systematically implemented by a
      few volunteers rather than imposed on all active developers)

    - having the local repos encourages more frequent (private)
      commits giving more flexibility in pushing; this helps to get
      small, obviously correct changes (like typo fixes and doc
      improvements) into the code base more quickly

    - better merging tools and efficient reversion tools make merging
      of conflicts and localization of bugs much more effective

The last two perhaps deserve some comment.  First, obviously learning
to push selectively, to use new merge tools, and to use new reversion
tools requires an investment.  However, this investment is repaid
*immediately*.  It is faster to learn to use git revert, then start
searching for the regression using that tool, than to just go "reverse
patching" and do the search that way.  (git bisect is even more
economical of developer time, if a scriptable recipe is available.)

Second, with focused changesets, a local repo, and a scriptable test
case, a bisection search over the sequence of revisions can be
automated.  In fact, git already has a "bisect" command, and I believe
there is a Mercurial extension to perform this task.  Inveterate
multitaskers will quickly learn to love this feature.

The productivity of the "kids" is harder to assess.  Their push rate
doubled, but so did the number of bugs manifesting in the bleeding
edge repo.  Of course the shallow bugs (build breakage, etc) also get
fixed quickly because they are easy to localize, but I worry (and
Emacs developers should account for when adjusting the project
workflow) that there are also deeper bugs being introduced more
quickly, and some are not getting caught.  Still the net effect is
apparently an increase in productivity.

This is a very important point.  Increasing the flow of contributions
(which dVCS will do, for *all* contributors, for the reasons outlined
above regarding "semi-conservatives") is not unambiguously good.  It
is not true that to "many eyes, all bugs are shallow".  What is true
is that (1) with many eyes, shallow bugs get caught very quickly, and
(2) that the more eyes there are, the more likely it is that some
member of the group has sufficiently penetrating vision to catch the
deeper-swimming bugs.

(No, I'm not trying to teach anybody's Grandma how to knit; probably
everybody knows this already.  But I hope to contribute a wording that
both the progressives and the conservatives in this debate can use as
a common ground.)

Re: dVCS vs. CVS

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > 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.
>
> No, but he did approximate it without any VCS at all.

Reality check.  He switched to using Bitkeeper exactly because he was
not able to keep up with development, getting stressed out, dropping
patches and so on.  And Linux development screeched to a crawl for a
number of months when the Bitkeeper license got revoked and Linus and
others coded git to usability in a frenzy.

So it is disingenuous to claim that Linus is not more effective while
using appropriate version control than when not doing so.

> And, AIUI, that is where Richard is coming from.

But Linus has long long ago left already.

> Admittedly, without a dVCS, to do what Richard does or what Linus used
> to do requires extreme talent as well as discipline.  However, with
> discipline it is possible for any developer to achieve fairly high
> productivity (explicit estimates in this list have been running about
> 20-25% less than with the tool, very small compared to the 10:1
> differences commonly reported for differentials across developers in
> both LOC and defect rate).

It is not that Linus is keeping secret his productivity gains from using
first Bitkeeper, then git.

The reason he was pressured to start using such a system was titled
"Linus does not scale well".  And in contrast to Richard, Linus is not
distracted by as many different tasks as speaker, lobbyist and president
of the FSF.

> Now, I see no reason to believe that Emacs is lacking such discipline.
> The behavior of Richard, Eli, and Alan leads me to believe, on the
> contrary, that there is a powerful discipline here.  If so, such a
> discipline is a more or less fixed investment, that shows up in a
> reluctance to change workflow.  That reluctance is well-justified!

Richard is only intermittently with net access and/or time.  With
distributed version control, managing more than one construction site at
once between checkins and working with experimental code would become
quite easier.  Of course, in the long run we will be better off with a
project manager with better availability, but dVCS would at least soften
the impact of not being continuously available and online.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: dVCS vs. CVS

[Stephen J. Turnbull]

David Kastrup writes:

 > So it is disingenuous to claim that Linus is not more effective while
 > using appropriate version control than when not doing so.

I didn't make that claim.  Throughout, I've admitted that better
version control can improve productivity dramatically.

 > > Now, I see no reason to believe that Emacs is lacking such discipline.
 > > The behavior of Richard, Eli, and Alan leads me to believe, on the
 > > contrary, that there is a powerful discipline here.  If so, such a
 > > discipline is a more or less fixed investment, that shows up in a
 > > reluctance to change workflow.  That reluctance is well-justified!
 > 
 > Richard is only intermittently with net access and/or time.  With
 > distributed version control, managing more than one construction site at
 > once between checkins and working with experimental code would become
 > quite easier.  Of course, in the long run we will be better off with a
 > project manager with better availability, but dVCS would at least soften
 > the impact of not being continuously available and online.

This, I claim, is wishful thinking.  The bottleneck is Richard's time
and connectivity, not the number of workspaces he has checked out
simultaneously.  He has also said he wishes Emacs had a more
continuously available maintainer, but for now he's it.  Anything that
threatens to disrupt his workflow is a threat to Emacs.

*I* agree that *in fact* git (or any of the plausible candidates) is
not a threat to his, or the project's, workflow.  All I'm trying to
do is to express that support for git (or other dVCS) in terms that
address the concerns that Richard, inter alia, has expressed.  I'm
also trying to explain to you that, AFAICS, you can tell Richard about
potential productivity gains until you're blue in the face, and he's
*still* going to ask "but, will it disrupt our workflow to convert? if
you say 'no,' why should I believe that?"

Re: dVCS vs. CVS

[Richard Stallman]

I think that arguing in the abstract about the various DVCS programs
and various ways of using them is taking up lots of time and is not
accomplishing much.

So let's await the study ESR is doing.  Until that is done, could we
please stop arguing about this?

Re: dVCS vs. CVS

[Bastien]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> (No, I'm not trying to teach anybody's Grandma how to knit; probably
> everybody knows this already.  But I hope to contribute a wording that
> both the progressives and the conservatives in this debate can use as
> a common ground.)

Your wording is crystal clear and very useful!

-- 
Bastien