thoughts on repository/storage/branch/checkout

Aaron Bentley aaron.bentley at utoronto.ca
Thu Feb 2 15:40:39 GMT 2006


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

Denys Duchier wrote:
>>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.
>>[...]
>>In our proposal, repository branches specify the exact locations of
>>their stores via a '.bzr/branch/store-location' or something.
> 
> 
> That seems to contradict the understanding that I thought I had gotten from
> lifeless on IRC.  If you specify the store location explicitly then you can't
> easily move a repo,

That is okay, we expect that to be a rare circumstance.

> unless said location is required to be specified relatively
> in which case that stipulation amounts to my notion of inheritance.

The location of the store for REPOSITORY BRANCHES is expected to be an
absolute URL.  The location of the store for STANDALONE BRANCHES is
expected to be the relative URL '.'.

Inheritance, to me, suggests that a branch would use the first enclosing
repository, whatever that might be.  Relative URLs don't have that property.

>>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 am not adding a concept, I am merely making it possible to freely and
> uniformely combine 4 primitive concepts, each one very circumscribed and thus
> hopefully easy to grasp.

As I mentioned earlier, the division is a matter of taste.  Your
concepts of STORE, BRANCH, and probably CHECKOUT are also divisible.

>  I think that trying to give names to all these
> possible combinations would be confusing - in fact the current overabundance of
> names _is_ confusing.

We need ways to describe the workflows we support.  That's the purpose
of terms like standalone checkout or bound branch.  Sorry that it is
confusing.

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

iD8DBQFD4if30F+nu1YWqI0RAtykAJ0UmisSzb7CVSmAiyM7ESMuu5Z0mgCfc9hr
4t28cC9gS/sJfa7ozv+wlpI=
=IHkX
-----END PGP SIGNATURE-----




More information about the bazaar mailing list