workingtree and branch

[John Arbash Meinel]

Robert Collins wrote:
> I think one reason the branch interface is overly large is that its
> supporting both workingtree and branch related functions.
> 
> I'd like to propose we split this by giving working tree the functions
> related to it - rename, move, move_one, revert etc.
> 
> This means a workingtree needs to know about its branch, so I further
> suggest that workingtrees have a .branch attribute, and branch loses the
> ability to construct a working tree - this switches the who-owns what
> responsibility.
> 
> Then, to get a working tree, one might have (in similar fashion to
> Branch.open, Branch.open_containing), WorkingTree.open and
> WorkingTree.open_containing, methods, but directly constructing one
> would be possible via WorkingTree(branch). (So
> WorkingTree(Branch.open_containing('.')) would be the common idiom for
> code that needs to translate a path to a WorkingTree).

I'm not sure about the WorkingTree.open(), but I think
WorkingTree(branch) makes sense.

I still think Branch is the class things revolve around, because it
defines the ancestry, what files are versioned, etc. And because we
could easily have branches without working trees, though a working tree
without a branch is just a regular set of files.

I'm curious, though. Would that mean that the .bzr/inventory (not
inventory.weave) would then be handled just by WorkingTree?

Seems reasonable enough.

John
=:->

> 
> Thoughts?
> Rob
> 

-------------- 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/20051016/d9ad982c/attachment.pgp