Checkouts? Or just light bound branches?

[Jan Hudec]

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.

> 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.

> 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.

> 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.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060127/8a90c27d/attachment.pgp