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

[Matthew D. Fuller]

On Tue, Feb 28, 2006 at 11:31:58PM +1100 I heard the voice of
Robert Collins, and lo! it spake thus:
> 
> Neither the repository object in a standalone branch nor a shared
> repository have 'branches added' in an internals-of-bzr sense.

But they do in a what-the-user-thinks-they're-doing 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.

I still think of this in particular as a somewhat-neat but weird
config; "repository" is something "over there".


> (*) svn and CVS repositories have the property that storage of
> branch content is shared between all the branches,

Part of the issue here is that "repository" means two things in this
[CVS/SVN] world.  One is the explicit "where history is stored".  The
other is the implicit (but no less strongly embedded for it)
"completely separate from my working tree".  It's not inside or
alongside the working tree, it's not a parent directory of it, it's
some place off in another directory or on another machine.


I think we have to examine the three cases separately.  Whether
they're the same in an internals-of-bzr sense is rather beside the
point in a user sense; they don't care what it is, they care how it's
used.  (following prescriptive language is all IMAO, naturally)


First off, we have the standalone branch.  This has a <blurgle> that
fulfills the first criterion, but fails the second.  It's an integral
package with the working tree.  For that reason, calling it a
repository causes more confusion than not.

Note that this doesn't mean that saying it's LIKE a repository is a
bad idea; as far as I've been able to determine, "A standalone branch
is _like_ a repository and a checkout bundled together" is the only
rational way to describe it to a CVS-minded person.  But extending
that to "Then you commit, and the revision gets stored in the
repository" conjures up the wrong connotation, because of that second
meaning.  If that part of a standalone branch ever needs to be
referenced, calling it the "history" or "revision store" is probably
better.


Secondly, there's a repository in /my/expensive/raid/repo/, that I make
checkouts from in ~/work/.  Here, even though a lot of lower-level
details may differ from the pre-existing "repository" concept in
people's heads, the workflow is nearly identical.  Here, the work can
transfer with hardly more than a hop, skip, and a jump.


Thirdly, there's the weird hybrid case where I create a <blurgle> in
~/work, and then create a branch at ~/work/foo, and it stores stuff
"centrally" in the ~/work <blurgle>.  In effect, I'm acting like (and
maybe thinking) I'm creating a standalone branch, but it actually
stores stuff up a level or three in the <blurgle> I created.  This is
Just Plain Weird(tm), and doesn't really have any equivalent.  Like
the standalone branch, it fails the second qualification, so
"repository" gives a rather odd connotation.  I'd suggest this be
called simply a "shared store".


Because I can already feel the response coming, I'll repeat that it's
entirely irrelevant that, code-wise, cases (2) and (3) are precisely
the same, and (1) is nearly so.  How they feel to a user ranges from
somewhat to totally different, and the pre-existing term 'repository'
applies well to case (2), hack-and-fit to case (3), and hardly at all
to case (1).  So, use it where it applies well, and leave it be where
it doesn't.


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.