On Tue, Aug 21, 2007 at 08:36:40AM +0800, Steven Grimm wrote: > I wonder if it makes sense to expose a repository locking mechanism for this > kind of application. The builtin git commands would test for the lock and > block (waiting up to some configurable timeout) until it went away, but > wouldn't necessarily ever actually lock things themselves. Or maybe a > shared/exclusive lock (aka an rwlock) would be appropriate here; the > repository-altering commands would grab a shared lock. For this use case, I don't think you need to touch the core git commands at all. Since we're just talking about a repo that people are pushing into, why not just grab the lock in a hook before accepting the push? That serializes the push, but each push can do arbitrary work while holding the lock. -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
