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

Tue Feb 28 13:42:34 GMT 2006

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.

 3. We rename shared repositories into something else. This seems to be
    the method that Jan is in favor of.

> > We don't want want to call the as-yet-unnamed thing repositories at the
> > same time that we call the thing that holds revisions in standalone
> > branches repositories. This would leave the documentation and the users
> > in a confusing state in which we'd sometimes say "a repository that holds
> > multiple branches" and other times "the repository in a standalone branch,
> > which doesn't hold any branches at all".
> 
> I don't think we need have any confusion. 'shared repository' and
> 'standalone repository' is all the separation needed to be unambiguous.
> Furthermore for documentation where the *presence or absence* of a
> standalone repository in a branch matters, then you are either talking
> about manipulating branches via cp & mv *after* talking about using
> shared repositories, or you are talking about storage optimisation. Both
> cases where its deep into the issue and entirely appropriate to be
> talking about both configurations.

I was certainly confused to learn that standalone branches had
repositories! I can't imagine, in the situation you describe, how
confusion would not be common.

> > The question is not "will there be a new term". The first question is actually
> > who gets the new term ("the thing that users can store multiple branches
> > in" or "the generic name for something that stores revisions") and what
> > that term shall be.
> 
> -1 on a new term. I think that adding a spurious term when from a user
> perspective a shared repository is much like a CVS repository or a svn
> repository (*) is harmful, and I think that telling people that the
> underlying mechanisms are different (by using a substantially different
> term) when they are not is in fact harmful to understanding. 

I'm actually in agreeance with you in spirit. Since 'shared repositories'
are so similiar to 'cvs repositories', that we should just call them
'repositories' too.  That's actually where the conversation started off,
way back when it was on IRC. 

Jan disagrees with this because standalone branches also have a repository
as well.

I'd personally be thrilled if we renamed 'shared repositories' into
'repositories' and renamed the repositories in branches to 'unshared
repositories'.

> Rob
> 
> (*) svn and CVS repositories have the property that storage of branch
> content is shared between all the branches, that all the different
> projects have urls that are suffixes of the root of the repository, and
> for svn but not CVS that the url to a branch is also a suffic of the
> root of the repository. (CVS branches are not available via the URL
> namespace, so this property cannot hold for CVS).
> 
> 
> 
> -- 
> GPG key available at: <http://www.robertcollins.net/keys.txt>.

-- 
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/20060228/1b724ff9/attachment.pgp 