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

[Erik Bågfors]

2006/2/28, Robert Collins <robertc at robertcollins.net>:
> 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.
>
> > 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.
>
> 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.
>
> > 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.

+1

> 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.
>
> > 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.
>
> 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).


FWIW, I agree with everything Rob says.

/Erik