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

[Jari Aalto]

jblack at merconline.com (James Blackwell) writes:

> On Thu, Mar 02, 2006 at 11:22:50AM +1100, Robert Collins wrote:
>
>
>                       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 shared 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. 

Thank you for the picture, I wish everyone used those more that just
talk about terminology and introducing terms that doe snot resemble no
any other other familiar thing in VCS (basket? huh?)

My position: I'm new to distributed VCS, so I have no baggage of Arch
=> Bzr transition. I only understand what RCS/CVS/SVN repositories
are.

Ok, so how do I understand repositories in Bzr? It's quite simple,
they are all:

        repositories

Confused? Not really. The developers may see distinction there where
there isn't one. It doesn't matter if it's technically called shared
or private, or some other thing, it's still plain:

        repository

To differentiate this better, adding a finer term in addition will
certainly help:

        shared repository
        private repository (or "unshared")

Of which the

        branches

spring into existence. The terminology does not have to be "exact" but
only sufficient, when its aim is to communicate the concepts to the
user. If the documentation aims to communicate to other developer,
then it must dwell into details. For average user

        {shared, private/unstared} repository + {type of} branch

term are all they need. The less terminology, the better.

Jari