Checkouts? Or just light bound branches?

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
>>>> 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.
> 
> Hmm.  I would think it works by analogy from the two-branch case.
> You could handle the LAN->public segment with a cron script, but I don't
> think that would work well if anyone else is committing to the public
> repository.
> 
>>>>>> 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.
> 
> This is what I mean by "worse than useless":
> When you want the latest code, anything that isn't is useless.  I'd
> suggest that no one wants out-of-date code.  But if the tree appears to
> be the latest code and it's not, then it's worse than that, because it
> causes people to waste effort working with the wrong version.

If I have a website, it is better to have a slightly out of date
version, than to have nothing.

> 
>>>>>> 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.
> 
>>> If you can't access your repository, then you can't do 'log', 'status',
>>> 'diff', or any of a number of things. 
> 
> This is true whether you unbind or not.  It's also true for checkouts.
> 
>>> 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'.
> 
> Okay, we can make that impossible in the UI if there's no good reason to
> do it.
> 
>>> 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?
> 
> The filesystem storage is similar, sure.  The set of objects involved
> would be different.
> 
>>> So what is a 'lightly bound branch' after I unbind?
> 
> I dunno.  (looks around desk)  We could call it a 'stapler', I guess.

I for one look forward to my new stapler overlords. :)

> 
>>> 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. 
> 
> My question is still, why would you want that?  If you have to log in to
> the remote host in order to update the working tree, why not just ssh in
> and pull?
> 
> Or, if you can't log into the remote host, then the whole issue goes
> away, because you can't have local changes.  You can just use rsync.  Or
> a smart server.  Or maybe we can make sftp just smart enough to
> overwrite the existing tree.

Because maybe I can't ssh, but you can.

> 
> Aaron

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