Re: base

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: miles@gnu.org,
>     emacs-devel@gnu.org
> Date: Fri, 27 Aug 2010 14:43:05 +0900
> 
> Eli Zaretskii writes:
> 
>  > Thanks.  However, what you wrote just shows once again that we are
>  > talking on two very different levels.  Your "user" is actually a
>  > hacker who wants to know and understand a lot about low-level
>  > details of the tool's operation.
> 
> No.  I'm saying that the project needs a few users who understand at
> that level, and that therefore it is important to have such a model.

This is the first time this particular issue comes up.  Until now, the
views with which I was arguing seemed to tell that _any_ user needs
such an understanding to use a dVCS safely and efficiently.

> I apologize for not making it clear that I do understand that average
> users can do fine without deep understanding (but with competent
> guidance).

That's okay, at least we are now in partial agreement.  Not sure
others agree, though.

> My main point is that somebody like you who has intervened in the
> process of recommending workflows really should have a good model.

Maybe.  I simply don't yet have enough experience to make my own
opinion.  Neither does Emacs as a project, I think.  So I will take
your word for it, for now.

>  > quite efficiently (no thanks to bzr docs), without having a
>  > slightest idea how it represents the history DAG or what are all
>  > those files in the .bzr subdirectories of my repository.
> 
> Er, Eli, I didn't mention any of those files (or their analogs in
> git), and I don't recall the docs I pointed to describing them,
> although it did mention their existence.

The docs you pointed to do describe them.  This page, for example:

  http://book.git-scm.com/1_git_directory_and_working_directory.html

>  > Contrary to what you say, these are, IMO, private data, not public
>  > data; for example, if bzr changes its repository format, I as a
>  > user don't care as long as there's a simple way of upgrading to the
>  > new format.
> 
> But the point is that often there isn't a simple way.  In fact, on one
> of my platforms I'm currently stuck without a usable bzr because
> Ubuntu Jaunty provides bzr 1.13, and that doesn't do format 2a, which
> is required for Launchpad.  Upgrading Ubuntu is not an easy option for
> me, either.

Well, when things get broken, you need a technician to fix them.  Most
users aren't technicians.  Projects shouldn't choose tools that become
broken or could break the project to the degree that most users
couldn't fix without calling a technician.