thoughts on repository/storage/branch/checkout

[Aaron Bentley]

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

Denys Duchier wrote:
>>It does not seem unreasonable to expect a file server's mount point to
>>be the same on all software development machines.  Certainly, there are
>>many ways to make it so if it is not.
> 
> 
> I am not sure how that would work when you mix Unix and Windows.

You're right.  It might be necessary to resort to another protocol.
Relative paths would be another option, but they restrict the kinds of
movement permitted within the repository.  I really don't want
inheritance, because I don't want the possibility to exist that
revisions could be stored in the wrong place.

>>Inheritance would also mean that you could confuse matters terribly if
>>you wound up in a situation with nested repositories.
> 
> 
> now who's reaching for a strange and unlikely example? :-)

Unfortunately, I think it's quite likely that someone will move a
Standalone Branch into a repository directory, and then create or move a
Repository Branch inside the Standalone Branch.

>>That was in response to your assertion that you were not adding a
>>concept.  I still hold that since my model has 3 concepts and yours has
>>4, that you have added a concept.
> 
> 
> Fine. ignore the WORKDIR primitive since it so rubs you the wrong way.  What
> about the STORE/BRANCH/CHECKOUT subset together with the regular ways of
> combining them.

Those are fine.  The're pretty much what we had already described, aside
from changing the name of Repository to STORE.  Your STORE is the actual
meaning of repository, as expressed in the code.  The rest is just
proposed policy.

> I appreciate that you are trying to come up
> with clear terminology for the relevant cases, it's essential for effective
> communication.  But terminology by itself does not reveal any underlying
> regularity / simplicity / beauty of design.  It will only provide names for a
> selected number of cases.

The terminology we've been using for what we considered the
'fundamentals' was: Repository, Branch, Checkout

In these discussions, Repository may have been overloaded (sometimes
being a container of branches, sometimes not).  Personally, I like the
notion of Repositories being aware of any branches they contain.

> This is why I wanted to take a step back, forget about the difficulty of coming
> up with clear terminology for the constructions which are expected to be most
> useful, and instead try to understand these various constructions as arising
> from a set of primitive concepts and a set of operations to combine them.  I was
> looking for a simple and regular formal system that (to me) would represent the
> essence of the system.
> 
> If you have such a system, then I'd love to hear about it.

The standard system is:

Repository
 - contains all revision data:
   - revision metadata
   - inventories
   - file contents

Branch
 - contains an ordered series of revisions
 - other misc metadata, like branch nick, parent location, binding data
 - refers to a repository

Checkout
 - contains a working directory
 - contains metadata associated with files in the wd
 - has pending-merges metadata
 - has a last-revision pointer
 - refers to a branch

The physical layout of repositories, branches and checkouts permits any
or all of them to be present at a given location, and to nest.

The model I proposed in the light bound branches thread replaced the
Checkout concept with the weaker Working Tree concept, removing the
notion of a separate last-revision or branch-location for the work
directory:

Branch
 - contains an ordered series of revisions
 - other misc metadata, like branch nick, parent location, binding data
 - refers to a repository
 - may contain a WorkingTree

Working Tree
 - contains a working directory
 - contains metadata associated with files in the wd
 - has pending-merges metadata

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

iD8DBQFD4lsc0F+nu1YWqI0RAnvAAJ9lrQTHJA+rYNGkeOHifN/Q9LcdiwCeLZFi
6LWV9V5AcuOHg6X1jRKFaQg=
=xrYC
-----END PGP SIGNATURE-----