[RFC] New name for 'repositories' - 'baskets'

[James Blackwell]

On Thu, Mar 02, 2006 at 11:22:50AM +1100, Robert Collins wrote:
> > > I don't understand how calling the same object doing the same job as
> > > both the large scale repository and the small repository storing history
> > > for a single branch different names can be a good idea.
He agrees with me?

> > > I think I need to -see- this confusion in action.
He disagrees with me?

> > In the prior sentence you seem to disagree. In the paragraph prior to
> > that, you seem to agree. 
> 
> I'm not sure which ordering you mean there, but for clarity: I'm
> describing how big the delta is in behaviour [its tiny] so that we can
> actually assess the cost of giving the two behaviours different base
> names vs different qualifiers.
> 
> > I can go on at length for why this should happen. I can refer to the
> > requirements of good writing (clear & internally consistant). I can
> > explain that writing is dependant upon terminology in the terms of
> > building blocks and stable foundations.  I can remind you of the mandate
> > that Bazaar-NG be easy to use is dependent upon Bazaar-NG being easy to
> > learn.  I can even provide numbers if thats what it takes.  Explaining
> > need for the change is easy.
> 
> Not really. Good writing is orthogonal to this issue - it needs to be
> good however we choose; choosing stable terminology is also orthogonal -
> once we take a position, we keep it - thats easy. Having this easy to
> learn is *what* this discussion is about. 

Ok. We're on the same page for goals. =)

> > What I can not do is express why you're against this. There seems to be
> > general, but not unanimous,  agreement that changing the terminology
> > somehow would help when it comes to describing Bazaar-NG to others.
> > 
> > Can you please enumerate your concerns for changing the terminology for
> > 'shared repository' ?
> 
> If we make this into a new concept when it does not need to be then we:
>  * Raise the bar for understanding bzr for new users
>  * Make it harder to explain 
>  * Make it harder to reconcile the external and internal behaviour which
> will impact the number of contributors that make the transition from
> user to developer/hacker.

I can see your point when it comes to the third bulletpoint. A conceptual
model that doesn't match the API model would raise the bar from going from
user to hacker.  I'm not sure why you listed the two former bullet points;
that is the two arguments that Jan and I have been making all along!


                      Repositories in Bazaar-NG
Repositories in      ,--------------------------.
  CVS / SVN          |     Repository Concept   |
 ,------------.      |  ,---------------------. |
 |Repositories|<------->| Shared Repositories |<--AKA. 
 `------------'      |  `---------------------' |  shared storage 
                     |  ,---------------------. |  bzr make-repository
                     |  |Unshared Repositories|<--AKA
                     |  `---------------------' |  standalone branches 
                     `--------------------------'                     


The problem is that the concept of repository in CVS/SVN and the concept
of repository in Bazaar-NG does not map well. The closest thing to a
CVS/SVN repository in the Bazaar-NG world is a Shared repository. So, when
you write docs for a CVS/SVN user and teach them Bazaar-NG from what they
know, you have to say "The repositories you were used to in CVS/SVN are
now called sahred repositories." That leaves open a logical fallacy
(begging-the-question to be precise because there's no yin without a yang)
of what an "unshared repository" is. 

Documents are different than code. The user can try and read documents in
any order they wish. That means every document has to define every term it
uses. This in turn means that every time repositories are mentioned in
docs....

Oh, never mind. You want to call them sahred repositories, we'll call them
shared repositories.



-- 
My home page:   <a href="http://jblack.linuxguru.net">James Blackwell</a>
Gnupg 06357400  F-print AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060301/d68023fc/attachment.pgp