Re: base

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Wed, 25 Aug 2010 23:06:59 +0200
> 
> I will not be so foolish to argue with you about what you had in mind at
> the time, but it looked like "I want to obtain the necessary knowledge
> to *decide* what is the most effective way of working with bzr for me."
> A good answer for that sort of request is pointing to a document
> explaining the foundations of the tool, from which everything else
> derives.

That wasn't the answer I was expecting.  I expected to see several
possible workflows with some analysis of their merits and demerits.
There's no need to know how a repository stores its info for that.

> >> http://www.newartisans.com/blog_files/git.from.bottom.up.php
> >
> > Once again, this is internals, not something users should need to
> > grasp to use the tool effectively.
> 
> You can use git effectively (for some reasonable definition of
> effectiveness) without knowing those details. Knowing them helps a lot,
> though. And they are not internal details, for the same reason that the
> point, the mark, etc are not internal details for the Emacs user,
> although you can use Emacs without knowing them.

Mark and point _are_ internal details.  Most users don't have a clue
about their implementation, not even about the fact that their API is
a function (as opposed to a variable, for instance).  What users are
told is some "model" of mark and point, and the model actually has
more to do with _what_ these do than how they do it.

> > IOW, a "mental model" is rules of the game, they have nothing to do
> > with the under the hood machinery that actually makes the game tick.
> 
> That document explains, precisely, the rules of the game, i.e. the model
> that every git implementation must follow.

I meant the rules of the game for the user, not for the
implementation.  Users should not be bothered by implementation
details.

> > I have no idea what is the underlying model in Bazaar, and I don't
> > really care how complex it is, as long as its UI is simple enough for
> > me to build my own mental model.  And as long as the UI is simple
> > enough, I see no reason to change the underlying model.
> 
> And if a merge causes unexpected results, what would you do? Blame the
> UI?

I'd say there's a bug that needs to be fixed.

> > I can also tell you that after spending a year studying the display
> > engine of Emacs, I think nothing can ever seem complex to me ;-).
> > What I did learn during this year is that complex models are not
> > necessarily bad or ugly or not extensible: look what I was able to do
> > with the display engine without changing anything in its basic
> > architecture and design.
> 
> I guess that most part of that year was consumed by the study of the
> *implementation* of the display engine, not its model (unless you
> learned the model by reading the implementation.)

Of course! because I needed to _extend_ the display engine.  But as a
bzr user, I do not need to extend it, so I shouldn't need to bother
about such details.