Checkouts? Or just light bound branches?

[Jan Hudec]

On Fri, Jan 27, 2006 at 12:37:53 -0600, John A Meinel wrote:
> 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 working tree thinkg is orthogonal. Branches may have working trees just
as checkouts have working trees. And both checkouts and 'light branches' use
the storage of the parent, so that is updated in both cases.

Ok, I'll try to explain the thing once again, hopefully more clearly:

What objects there would be and what attributes they'd have:

    WorkingTree
	hashcache
	the actual files
	# This is there in any case
    Checkout
	current_revision
	branch_location
    Branch
	current_revision
	[optional] parent_branch_location
	# In case of a bound branch
	storage_location
    Store
	all the weaves and revisions

Now don't the Checkout and Branch look suspiciously similar? We could make
Checkout a special case of Branch, that has storage location equal to
storage_location equal to that of parent branch. Then if we handle the case
that bound branch parent is a bound branch too, functionality remains the
same, but there is one object less.

Ok, I understand that probably the plan is to put the Checkout stuff into
WorkingTree. The question is which is simpler -- I think using a Branch for
it is.

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

No. Checkout is bound.

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