thoughts on repository/storage/branch/checkout

[Denys Duchier]

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

> | Whenever a concept A depends on another concept B, there is the
> possibility
> | that:
> |
> |     - 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.

> BOUND is another concept, one that you have not addressed here.  Call it
> a LIGHT BRANCH.  (In my proposal, I was saying that these LIGHT BRANCHES
> should also be BOUND, but it's not a logical necessity.)

you are right: I wasn't sure what to call them. "light branch" it is.

> |     - 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.  In the typology that I am proposing here a branch never
_has_ a checkout as such.  It is unfortunate that I have to use the same words
with slightly different meanings than those currently accepted in bzr, but
imagine that I say store', branch', checkout', workdir': those are new words,
naming new concepts that are very closely related to their non-primed variants.

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

> |
> | CHECKOUT
> |     a checkout depends on a branch and on a workdir.
>
> 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.  In current bzr, the workdir's checkout' is always
inherited (in my sense).  With a dislocated workdir, you have to explicitly go
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.

> You're on the right track, but I don't think you have a clear grasp of
> bound branches.

I think that was cleared on IRC (thanks to all who help me debug my
understanding, especially jblack's apparently inexhaustible fortitude in this
regard).  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".  My typology indeed doesn't address the
notion of a branch being "bound", nor should it: the notion of being "bound"
affects the behaviour of certain operations, but the underlying object, on which
these operations operate, is unchanged and fits in my proposed typology.

Cheers,

--Denys