Checkouts? Or just light bound branches?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD2n5J0F+nu1YWqI0RAo62AJ9/jEjqFK1VBj1GNhm8+Sm/LxFWCACcCup3
378pzXV570nJqGXRUXBaZpU=
=gmIW
-----END PGP SIGNATURE-----