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

[John Arbash Meinel]

James Blackwell wrote:
> On Tue, Feb 28, 2006 at 11:31:58PM +1100, Robert Collins wrote:
>> On Tue, 2006-02-28 at 07:10 -0500, James Blackwell wrote:
>>>> On 2/28/06, Jan Hudec <bulb at ucw.cz> wrote:
>>>>> On Tue, Feb 28, 2006 at 17:13:03 +1100, Michael Ellerman wrote:
>>>>>> I haven't read the code that does repositories, and maybe that's a
>>>>>> good thing, but my intuitive idea of "repository" is a "place where
>>>>>> there's a bunch of branches". Is that too far off?
>>>>> No. It's not.
>>>> Well I think it's reasonably close, although I agree it's not exactly right.
>>> No, its definitely wrong and exactly how this converation came up.
>>>
>>> I used "repository" in this sense while describing the place that one can
>>> store multiple branches while taking advantage of stored storage. This
>>> definition is wrong, though, as standalone branches have a repository that
>>> does not allow one to add extra branches.
>> The sentence 'This definition is wrong, though, as standalone branches
>> have a repository that does not allow one to add extra branches.'
>> indicates some confusion I think.
> 
> I agree that confusion exists. Regardless of whom you point at, that
> confusion exists is palpable. It seems to me that there are plenty of
> reasonably bright people present. Each person has a subtle, but
> incompatible, understanding of what means what.
> 
>>> My undestanding of repository is that its a place where revisions are
>>> stored. This means that a repository is part of standalone branches and
>>> part of a as-yet-unnamed thing in which one can put multiple branches into
>>> it.
>> Again. 
>>
>> Neither the repository object in a standalone branch nor a shared
>> repository have 'branches added' in an internals-of-bzr sense.
> 
> When I said "branches added" I was referring to revisions. To me, in a
> 'shared repository' is a collection of revisions that can be used, with
> additional data, to reproduce the history of one or more branches. The
> 'repository in a standalone branch' only has the revisions for the
> standalone branch and no others.
> 
> Incidentally, this is a good example of another, larger, problem at hand.
> Documention for new users is a explanation with reduction and
> simplification of the technical terms. I inevitably get hit by somebody
> each time I attempt to reduce concepts to pieces that are small enough
> that users can understand.
> 
> I suppose I could give up on the reduction part and preach specifically
> the terms as they mean, though it will come with the cost of giving the
> impression that the tool is "easy to use"
> 
> 
>> I refer to 'shared repositories' to talk about repositories which are a
>> parent directory of many branches, and those branches have no repository
>> co-located at their directory.
> 
> Yes. We all agree with this. The problem is that we're using the term
> 'repository' which is incompatible with the CVS/SVN world. There's two
> ways to deal with this. 
> 
>  1. We not rename anything. CVS/SVN get confused because standalone
>     branches have repositories and the thing that they're used to thinking
>     is a repository is now called a 'shared repository'.
> 
>  2. We rename 'shared repositories' into 'repositories'. This means that
>     there is a need to come up with a name for what we currently call
>     repositories. I'm in favor of this option.

+1 on changing the name of 'standalone repository', and renaming 'shared
repositories' to 'repositories'.  I think 'repository' is the user-level
term, of a group of branches.

I don't know what a good alternate name is for the internal stuff.
(Heck, we could call it an 'archive' :))

archive, store, collection, ancestry, history, oldstuff, box, ...
nothing is all that good.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060228/42fdfafb/attachment.pgp