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

[Robert Collins]

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



-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060228/b940f8a0/attachment.pgp