Checkouts? Or just light bound branches?

[Robert Collins]

On Thu, 2006-01-26 at 15:15 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> It somewhat bothers me that checkouts and branches both have the concept
> of last-revision.  Considering that revision-history is the only concept
> that Branches represent, there's a lot of overlap.

Hmm. Well Branches represent the sequence, checkouts the point in time,
IMO.

> It also bothers me that bound branches and checkouts will have the same
> behaviour implemented around last-revision: if local last-revision is
> not the same as upstream last-revision, fail.

for commits you mean? Yes, that workflow would be the same. But I would
expect that it is implemented *by the checkout code* in both cases. A
bound branch has a checkout that is generally the local branch, so if
you pull the remote branch into the local branch without altering the
checkout, then trigger the commit, you'll get the same behaviour with no
duplicate code.

> Bound branches and checkouts will serve very similar use cases, so it
> seems funny that they use different concepts, and will require different
> day-to-day operations.

I'm not sure what different operations you are thinking of here...
except that bound branches can work offline

> Until now, I haven't had much idea what to do.  But I just had one:
> instead of checkouts, use branches whose repositories are elsewhere.
> 
> This works nicely in that we're planning to allow branches to specify
> their repository location anyhow.
> 
> In terms of the local data location, little changes.
> 
> Checkout             Light Bound Branch
> ========             ==================
> - - inventory          - inventory
> - - pending-merges     - pending-merges
> - - branch location    - repository location
>  (implies repository
>   location)
> - - last-revision      - revision-history
> 
> In the repo, you still have a branch that is up-to-date, unless you
> slacken the binding.
>
> I voiced a similar suggestion in the "Re: redirected and shared working
> trees" thread, but at the time I was talking about unifying the UI of
> checkouts and bound branches, not unifying their type.
> 
> Any thoughts?

codewise:
I think that this would be somewhat artificial, as I think all the
workflow code for bound branches is most appropriate to live in the
workingtree anyway.

uiwise:
I'm not sure from a UI perspective if its a problem or not to expose
both checkouts and bound branches or not - but using 'lightweight bound
branches' would have the same ui consequences anyway.

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/20060127/d056d6d9/attachment.pgp