Bound branch implementation

[Robert Collins]

On Mon, 2005-11-14 at 23:39 -0600, John A Meinel wrote:
>  
> > ...
> >         # TODO: Should unbinding a non-bound branch fail?
> > +        #bzr('unbind')
> > 
> > 
> > I think unbinding an unbound branch is an error.
> > 
> 
> I think right now it is an error (because the delete raises an
> exception, though LocalTransport is (slightly) borked because it should
> raise NoSuchFile, and instead it is letting the IOError be generically
> trapped into a LocalTransportError)

Heh.

 
> > 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.)
> 
> I would be okay with a blackbox package, but I generally don't prefer to
> have everything in one file.

Ok. Doesn't need to be part of this branch, but I think it would be good
to do soon.

> > 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.
> 
> Actually, I think performance-wise, having commit do all of the work
> locally, which can then be simply pulled up to the remote is just as
> clean. Especially with knits.
> I doubt we will get rid of set_revision_history, but I could be wrong.
> Certainly we could have commit do the operation.

So, performance wise, with what I'm proposing:
* revision trees come from local store
* inserting the file revision texts remotely is of no extra network cost
than inserting locally and pushing.
* ditto inventory and revision objects.

-> There should be no difference in performance.

> > 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 ?
> 
> The local revision history hasn't actually been modified yet, but I know
> what it wants to become. I can just pass in the revision_id (if I hack
> around a different check, which wants the revision_id to exist in the
> local revision_history), which causes it to use the
> "get_intervening_revisions" codepath.
> The biggest thing is that it was giving me a nicer exception
> (DivergedBranches), rather than giving me (NoSuchRevision).

Are you using the wrong branch object? I'll play with the code soon
myself, it just smells wrong at the moment.

> > 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.
> 
> But you just finished saying that it needs to be done at the commit and
> pull level, which are way above the actual Branch object. Commit is an
> entire semi-complex class in itself, pull is certainly implemented
> internally in the branch.

No - I said that hooking into set_revision_history was wrong, because it
changes a lightweight local-metadata operation into a potentially
heavyweight, syncronising with a remote branch operation.

> I think commit could go out and check that it is up-to-date at the
> beginning rather than at the end, but really it should do all of the
> weave updates and any other stuff on the local files, not on the remote
> branch. And then upload the changes when it has worked everything out.
> Why download the remote files, when you should have everything you need
>  locally. If you wanted to be pedantic, I suppose you could download
> just the table of contents (this is much easier with knits), and make
> sure you have the same contents.

Well, you can be sure that you won't have identical knits most of the
time (after any local change the TOC will differ even though the same
data is available). And with a bound branch you are *conceptually
committing to the remote one*. So, I think its entirely appropriate to
talk to the remote branch first.

> > 
> > In either case, a normal branch could have bind() on it, and BoundBranch
> > unbind(). :)
> 
> Except then you need to use "hasattr()" to detect which one you have,
> rather than catching the "branch is not bound" exception. If you *don't*
> use hasattr, then you get the AttributeError exception, which I think is
> bogus.

Heh. I was trolling there - the :) was meant to indicate that.

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/20051116/691c3755/attachment.pgp