thoughts on repository/storage/branch/checkout

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denys Duchier wrote:
> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
> 
> 
>>We do not consider the workdir to be separable from the checkout.
> 
> 
> I know, and I am proposing that it should be.

Yes.  I think I misunderstood the purpose of your email.  I thought you
were trying to recap our proposal, not make a similar alternative proposal.

> This is more uniform and makes it
> possible e.g. for several checkouts to have their worktrees reside at the same
> place (convenient for a practical case which I have described several times).

Concepts are almost infinitely divisible, so it's a matter of taste
where you draw the line.  I do think it's advisable to be conservative
in the number of concepts we use, because every concept increases the
learning curve for new users.

>>|     - B is local
>>|     - B is dislocated
>>|     - B is inherited
>>
>>We do not consider these to be fundamentals.
> 
> 
> I am suggesting that these _are_ the underlying notions as already evidenced in
> the proposed concepts "standalone branch", "light branch", and "repo branch".
> Some of the possiblities I describe are not currently exercised, but I am here
> trying to uncover the underlying regularities.

I am stating that "B is local" and "B is dislocated" are variations on
"the branch is in a specified location", which is the actual fundamental
concept.  I am also stating that we do not have a concept of
"inherited".  That is a new concept that you are introducing.

>>|     - the store is inherited (REPO BRANCH?)
>>
>>The main differences between a REPO BRANCH and a LIGHT BRANCH are:
>>1. the REPO BRANCH is in a subdirectory of the REPO directory
>>2. the REPO BRANCH has no CHECKOUT.
> 
> 
> I understand this.

The point I was making is that "inheritance" doesn't play into it.

>  In the typology that I am proposing here a branch never
> _has_ a checkout as such.

Yes, the concept of a line of development, or even its pysical
representation as a revision-history, does not imply a checkout.

Terms such as REPOSITORY BRANCH and LIGHT BRANCH refer to the compound
objects (or not-so-compound, in the case of REPOSITORY BRANCHES).  That
is, all these are terms for combinations and configurations of the
physical branch,

For example, the only observable difference between a STANDALONE BRANCH
(repo+branch+checkout) and a REPOSITORY BRANCH in the root of the
repository is that the REPOSITORY BRANCH has no checkout.

>>There is no inheritance, per se; the full path to the repository is
>>specified in its branches.
> 
> 
>>From what I understood, the proposed structure in a repo is supposed to be
> something like this:
> 
> $REPO/
>     README
>     .bzr/
>         repository/
>             repository-format
>             inventory.weave
>             revision-store/
>             weaves/
>     foo-branch/
>         .bzr/
>             branch/
>                 revision-history
>                 branch-name
>     baz-branch/
>         .bzr/
>             branch/
>                 revision-history
>                 branch-name
> 
> where repo branches foo-branch and baz-branch use the repo/.bzr/repository for
> their storage.  I call this relationship "inheritance": the store' comes from
> the enclosing repo; it is not "local" to the repo branch and a "dislocated"
> store' is not explicitly specified in foo-branch/.bzr/branch/store-location as
> it could be in my proposal.

In our proposal, repository branches specify the exact locations of
their stores via a '.bzr/branch/store-location' or something.

>>Operations on the checkout, e.g. add, commit, imply that there is only
>>one checkout per workdir.  It may be theoretically possible to split
>>them, but I believe that the result would only be confusion.
> 
> 
> re: confusion: I don't think so: you perform these operations in (and on) the
> checkout, not in the workdir.

These appear to be operations on files, not on checkout-relative paths.
 I hold that it *would* be confusing to do 'bzr add foo' when foo does
not exist in the cwd.

> to the checkout' in order to perform vcs operations.  Such a configuration would
> admitedly be infrequent, but it is one which would be quite convenient for me in
> some cases.

I do not think adding a concept to support your infrequent use is a good
tradeoff for a system that wants to be easy to learn.

> I wasn't sure how to call the "light branch" concept as, in going back
> through the mailing list archives, I had only managed to find it (more or less)
> under the name "light bound branch".

This is because unbound light branches seem like a bad idea, so we had
no need to name them.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD4hUZ0F+nu1YWqI0RAoIQAJwOHKFCyaC5OvRHvGUd/Css2PZ27QCfWE+H
IzALYPQ+2LyOMcLl/CliOcs=
=R8k4
-----END PGP SIGNATURE-----