Bound branches revisited

Erik Bågfors zindar at gmail.com
Mon Jan 2 09:42:56 GMT 2006


2006/1/2, John Arbash Meinel <john at arbash-meinel.com>:
> Robey Pointer wrote:
> >
> > On 31 Dec 2005, at 9:43, John A Meinel wrote:
> >
> >> Kevin Smith wrote:
> >>
> >>>
> >>> To answer the specific question above, I would have to ask what would
> >>> happen if I did:
> >>>
> >>>   Bind A to B
> >>>   A commit
> >>>
> >>> If B's working directory would be updated by the commit, then I would
> >>> expect this:
> >>>
> >>>   A commit
> >>>   Bind A to B
> >>>
> >>> to do the same. If the first case doesn't touch B's working  directory,
> >>> then neither should the second case.
> >>
> >>
> >> Yeah, that's what I ended up with. bind/commit/pull all do not update
> >> B's working directory. With the current system, there is no way to go
> >> into B and get it to merge the changes, so it is a little bit  broken. In
> >> the future, WorkingTree will keep track of its current revision, which
> >> will help with that.
> >
> >
> > Yeah, what I was about to suggest is that when A commits, B's branch  is
> > told "your working tree is now out of date" and B's working tree  is
> > turned into a checkout.  Is that basically what you're saying? :)   (I
> > haven't been following the working-tree threads closely.)
> >
> > robey
>
> In the future, all working trees will effectively be checkouts. Just
> with the branch information in the same place. I think it is generally
> simpler to work that way.
>

Does that mean that we have to work in the same way you do in
mercurial, where you run hg pull, and are totally confused by having
no changes? :)

/Erik




More information about the bazaar mailing list