Checkouts? Or just light bound branches?

[John A Meinel]

Jan Hudec wrote:
> On Fri, Jan 27, 2006 at 08:04:49 -0600, John A Meinel wrote:
>> 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).
> 
> And if checkouts are actually different animals, we need to support exactly
> the same operation, except the two steps would be done by different routines
> instead of one recursive. No advantage at all.

Actually, it isn't the same operation. One operation is updating your
repository information, and the other one is updating your working tree.
They are separate actions.

There is a tiny amount of code in checking to see if you are up-to-date.

> 
>> 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).
> 
> Um, no. It should remain as it currently is -- when the working tree is not
> updated, it has the reverse checkout applied and can be updated by revert.
> 
> There are only two cases anyway -- either noone cares about the working tree,
> or the working tree is updated properly.

Someone wanted the use case where he only has his desktop and his
laptop. And he wanted to be able to push changes between them.
If the only tool we have to update a "not the latest branch revision"
tree is 'revert', then he can't have uncommitted changes on his laptop
when he pushes from his desktop, or he will lose them.
To prevent this, all we need is a single file that can distinguish what
the working tree thinks it is at, versus what the branch thinks it is at.

> 
>> 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.
> 
> Why? Just as today, you would simply run revert on that tree after pushing.
> Or you would push over a smart server so the tree would be updated.
> 

Revert is really a big sledgehammer. It really doesn't have the finesse
of what you might want to do.

>> 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).
> 
> Just as a bound branch -- that's the point of binding.
> 
>> 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.
> 
> Sure you *can* unbind them! They share storage with their parents, just the
> same way branches in a repository do. When the parent is removed, you are
> screwed -- well, you are. Additionally an option
>   bzr unbind --unshare-storage
> to get regular stand-alone branch could be easily added.
> 

If you have unbound your lightly bound branch, then you have a checkout.
 The question is really only do we have a separate 'last revision' or not.

Having it separate introduces a little bit of complexity internally. But
not a lot, and I think it gives us flexibility in how we use remote
branches.

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