Mario, please don't reply in private. That way your mails won't get indexed and you don't have a chance to get help from others on the mailing list. While we're at it; don't top-post. Most people who frequent email lists with moderate to high traffic read hundreds of emails every day, so a quick reminder of what the discussion was about is useful when getting a reply. That reminder gets a lot trickier to get to if you first have to scroll down and then back up. Besides that, it feels totally backwards. Mario Pareja wrote:
Andreas, Thanks for the quick reply. You asked how I thought locking could have helped. I think locking helps notify a developer that a file is being modified _before_ the developer begins his/her own modifications. If I followed your example correctly, the conflict is identified after the work has been done - this is too late if you ask me.
So it's a communication issue then. The way I understand locks in svn and cvs is that they also only bother you when you want to check in the file you've just recently modified, or if multiple people want to lock the same file at the same time. If that's the case, I see no problem what so ever with teaching specific git commands to interact with a locking server. git lock (and git unlock) would have to be coupled with a git-lock-daemon with wich everyone communicates. It should probably have the ability to run a hook or something (centrally) when a lock is obtained and released, so as to be able to notify others that a lock is held. I might write this for fun some day, but it's really not my itch to scratch, and it would be a terrible mistake to add something like a central repository to take care of it when a single rather stupid daemon and an equally stupid program could do the same work but much more efficiently. Note that locking would be completely advisory though, and nothing would prevent people from committing changes to a locked file. Then again, insofar as I understand SVN/CVS locking, that's how those work too, except that an SVN "checkin" would be the equivalent of "git commit && git push" (the push part of the git sequence won't work). -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- 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
