> So it's a communication issue then. Yes, but I think the communication of this information needs to happen as part of a developers normal work-flow rather than requiring them to remember to check an external system. > 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. The SVN client will make locked files read-only until a lock is obtained for them. This helps "remind" you that a lock should be obtained before editing such a file. Requiring the developer to obtain a lock ensures that nobody else is editing the file and prevents wasted work. Upon commit, the file is marked as unlocked and the local file is once again read-only. > > Note that locking would be completely advisory though, and nothing > would prevent people from committing changes to a locked file. If git were to support locking then it could prevent people from committing without first locking. Even if it is not supported directly by git - perhaps using a lock daemon - a wrapper would need to be written around git commit/push to prevent developers from committing/pushing changes that would cause binary merging conflicts. > 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). > Generally in SVN you need to lock the file before being able to commit. Really, I am just curious about how others deal with this issue. Do you simply start editing binary files and hope nobody else edits the same file? Do you send out an email telling people you are working on such a file? Mario -- 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
