making checkouts, branches and repositories on disk - and the whole naming debate

John Arbash Meinel john at arbash-meinel.com
Tue Jan 24 20:57:25 GMT 2006


Robert Collins wrote:
> So there was a recent thread I now cannot find about the terms we use
> for checkouts, for checkouts + branches + repositories in one place, for
> branches in repositories (which then cannot have checkouts) etc.
> 
> We have an impending API clarity problem: we need to create each of
> these permutations from time to time, and while the primitives to create
> each separately will obviously have to exist, it would be nice to have
> shortcuts.
> 
> The problem is where these should go? In branch-formats, for example,
> I've created WorkingTree.create_standalone which creates a standalone
> working tree and branch. - its a neither fish nor fowl issue.
> 
> We have at least the following variations to create:
> working tree no branch
> working tree, branch, repository
> branch and repository
> branch in a repository
> repository
> 
> What these all have in common is that they are creating persistent
> structures on disk/at urls. So my thought is that if we have a factory
> object somewhere (I have no name for it yet), we can have methods like:
> 
> create_checkout
> create_standalone_branch
> create_treeless_branch
> create_branch_in_repository
> create_repository
> 
> 
> Theres a symmetrical problem - the open and open_containing methods.
> Sometimes we know what we want - 'commit' for instance must have a
> working tree. Sometimes we dont though: status and diff can operate with
> no working tree via the -r parameters. So we have some open_containing
> requests (presumably we have an open variation if desired):
> * give me the containing tree (or an error if a branch or repository is
> found before a tree) [commit]
> * give me the containing tree/branch/repository [cat-file]
> * give me the containing branch/repository (or an error if a tree
> without branch/repo is found first) [bind]
> * give me the containing repository (or an error if a tree or branch is
> found first) [make-branch-in-repository]
> 
> So I'm picturing one object with suitable methods on it to provide all
> of this, which might be a singleton, or they might be class methods. 
> 
> Thoughts?
> Rob

Right now we handle this by using WorkingTree.open_containing versus
Branch.open_containing. We use the former if we know that we need a
working tree, and the latter if we just need branch information.
However, we end up with code duplication (the open containing loop).

I wouldn't mind seeing something that just understood
'.bzr/branch-format' (and the future '.bzr/meta-format'). And this could
then be called by all other functions.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060124/08ec4ec0/attachment.pgp 


More information about the bazaar mailing list