Checkouts? Or just light bound branches?

[John A Meinel]

Aaron Bentley wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> Aaron

I want to think about the different use cases we wanted to support. With
my favorite one first. A published repository mirrored to a local
repository with checkouts into the working tree. This gives you space
savings on both ends, and still lets you work offline.

The issue is that the branches in the local repository should be bound
to the remote repository. And then they have a checkout pointing at them.

Switching to the 'checkouts are actually light bound branches' would
mean supporting double bound branches. Not terrible, especially as long
as one of them is local (so references are always resolvable).

The problem is I think we still need the concept that the working tree
has a 'last revision' which may be different that the branch it
references. Because of the 'push' issue.
That if I push to a remote tree, and don't update the working tree, it
is out of date. And I would like a way to update it, without potentially
loosing the minor changes that already exist. (Maintaining a website,
for instance).

Now, we could get around that by removing the ability to push to a
remote branch with a direct working tree. So on the server side you
would have to have a branch without working tree, and then a light bound
branch (checkout) next to it, rather than inside it.

The other thing is that a checkout can't really diverge, it can only
become out of date. (Until someone pull --overwrites the other branch).

Honestly, though, I'm not sure what does go into 'branch' other than the
last-revision, and some of the naming stuff (like nickname).

I'm not as bothered with both of them having last-revisions in them.

Oh and the other problem with 'lightly bound' is that you can't unbind
them. Since there is no local data to fall back on.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060127/f4a3c47c/attachment.pgp