Re: keeping remote repo checked out?

On Mon, 28 Nov 2005, Daniel Barkalow wrote:
> 
> We really ought to keep track of what the current checked out tree is, 
> independant of the head that it's supposed to match. Then it would be safe 
> to push to a head that's checked out (it wouldn't update it, but the 
> system would understand what's going on).

Well, that's what branches are all about. 

You really have two choices:
 - do it all yourself
 - use git branches

but if you use a special git branch for the checked-out state, then you 
have to realize that nobody can push directly to it.

You'd have a trigger that triggers on a push to _another_ branch, and then 
the trigger basically does an automatic "git pull" from that branch (and 
updates the checked-out state as part of that).

But you _still_ need to do the locking. That's very fundamental. There is 
no locking in a "git push", exactly because it can push in parallel, by 
design. And you _cannot_ check out a tree in parallel, so you have to do 
locking for that.

There's no way you can avoid the locking. You can do shortcuts: for 
example, you could avoid any explicit locking by having the "checkout" 
just happen once an hour, with an automatic "pull" from the changed 
branch. Again, that means that the branch that is checked out can NOT be 
one of the branches that people push to.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html