Bound branch implementation

[Robert Collins]

On Sat, 2005-11-12 at 20:50 -0600, John A Meinel wrote:
> One use case that comes up fairly often is wanting to have a public
> location where people can download your branches, while still having a
> local branch that you can use offline.
> Also, frequently people want to have some sort of centralized
> development, where they have a shared branch that multiple people can
> commit to. In this sort of mode, you have to update your local tree
> before you can commit.
> 
> So, I think I have an implementation which works. It is built off of
> Robert's integration branch, and is available from here:
> http://bzr.arbash-meinel.com/branches/bzr/bound-branch/
> 
> Eventually, we want to put this into bzr core, but first I would like to
> get some feedback. I made sure committing when bound has a decent error
> message, but I'm not sure that I've tracked down all the other
> possibilities.
> 
> My test cases work, indicating the functionality is there, but that
> doesn't mean the user interface is perfect. Also, I believe it will fail
> when bound to a remote tree, since we can't update remote WorkingTrees.
> I don't know if we will support updating remote trees, or just creating
> branches without remote working trees.

Heres some code level feedback ...

...
        # TODO: Should unbinding a non-bound branch fail?
+        #bzr('unbind')


I think unbinding an unbound branch is an error.


I think it would be nice to have all tests that call self.run_bzr in
selftest/blackbox.py - or perhaps we should make a blackbox package ?
(It means there is a predictable place to go to find ui level tests.)

hooking into set_revision_history seems very wrong to me. Firstly, we
may be nuking the concept completely. Secondly, I think its less clear ,
and more prone to confusion, than if we just do operations like commit
to the bound-to branch first. I.e. commit commits the local working dir
to the remote branch, then adds the same revision to the local branch,
and finally sets the local revision history.

Likewise pull --overwrite would affect the bound-to branch first, then
the local one. If interrupted both of these operations will simply need
a 'bzr update' or similar - at worst a update --overwrite - to reconcile
the branches.

in missing_revisions and update_revisions, why do you need to pass in an
other_history ? Is it an optimisation ?

get_bound_location should be @needs_read_lock. In general anything that
reads will need @needs_read_lock, and anything that writes
@needs_write_lock. Using these will cause caching to occur
automatically, where appropriate.

It might be nice to have a 'BoundBranch' branch class which incorporates
the bound behaviour. This would be returned as appropriate from
Branch.open/open_containing. I can clean up the code around there if
needed to make this easier. Alternatively, one could adapt a branch to
be a BoundBranch, though I don't know if thats feasible at the moment.

In either case, a normal branch could have bind() on it, and BoundBranch
unbind(). :)

I like the way its shaping up though, now for soft-failures!

Rob


Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051115/2c8dcd0d/attachment.pgp