Checkouts? Or just light bound branches?

[John A Meinel]

Aaron Bentley wrote:
> 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.
> 
> I agree that this is an important case.
> 
>>> Switching to the 'checkouts are actually light bound branches' would
>>> mean supporting double bound branches.
> 
> I'm actually in favour of supporting multiple-bound branches.  I think
> that would provide some useful flexability.  I can see wanting
> 1. local repository
> 2. LAN repository
> 3. public repository
> 
> And having them all autoupdated.
> 

I'm not sure if 'bound' is the place to do it, as you have the issue of
who the master is. But it could work.

>>> 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).
> 
> so:
> $ bzr push sftp://aaronbentley.com//home/abentley/myproject
> $ ssh aaronbentley.com
> $ cd myproject
> $ bzr revert
> (local changes lost)
> This is the kind of thing you mean?  (It can be worked around with
> merge, but not conveniently.)
> 

Correct. Right now, this is the only way to update a sftp branch. And it
only works if you have ssh access, and will lose local changes.


>>> 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.
> 
> You'll recall that I'm strongly opposed to the current behaviour.  "If
> there's a tree, we should either update it or fail to push.  An
> out-of-date tree is worse than useless."
> 

Well 'worse than useless' is a little bit strong. But I do think we
should be able to do a lot better.


>>> I'm not as bothered with both of them having last-revisions in them.
> 
> Well, I'm not lying awake at night.  It just suggests to me that our
> current model may need refinement.
> 
>>> 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.
> 
> You can unbind them; you just can't commit if you can't access your
> repository.  For the checkout-of-local-bound-repository-branch case, you
> would never be unable to access your repository.
> 
> Aaron

If you can't access your repository, then you can't do 'log', 'status',
'diff', or any of a number of things. I think there are people who want
to do a 'checkout' of a central branch. Exactly CVS like. I don't think
you should be able to unbind a 'checkout'.

With lightly bound, I guess you could unbind them, and they still have
their storage somewhere else. But if you have your storage somewhere
else, then you have a checkout. Isn't a 'light branch' a checkout?

So what is a 'lightly bound branch' after I unbind?

I'm certainly okay with:

Full stand-alone branch has: .bzr/repository, .bzr/branch, .bzr/checkout
branch inside repository has: .bzr/branch
'checkout' has: .bzr/branch, .bzr/checkout

Where 'repository' has the text weaves and revision store, 'branch' has
'branch-name' and 'revision-history', and checkout has 'inventory',
'basis-inventory', etc.

The question still becomes can we support pushing to a location such
that we update the branch it thinks it is on, without updating the
working tree. If 'checkout' has a last-revision, we can do this. If it
doesn't, then we should forbid pushing to a tree that we can't update
the working tree.

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