Locking binary files using git version control system

Question

For one and a half years, I have been keeping my eyes on the git community in hopes of making the switch away from SVN. One particular issue holding me back is the inability to lock binary files. Throughout the past year I have yet to see developments on this issue. I understand that locking files goes against the fundamental principles of distributed source control, but I don't see how a web development company can take advantage of git to track source code and image file changes when there is the potential for binary file conflicts.

To achieve the effects of locking, a "central" repository must be identified. Regardless of the distributed nature of git, most companies will have a "central" repository for a software project. We should be able to mark a file as requiring a lock from the governing git repository at a specified address. Perhaps this is made difficult because git tracks file contents not files?

Do any of you have experience in dealing with git and binary files that should be locked before modification?

NOTE: It looks like Source Gear's new open source distributed version control project, Veracity, has locking as one of its goals.

Answer 1

Subversion has locks, and they aren't just advisory. They can be enforced using the svn:needs-lock attribute (but can also be deliberately broken if necessary). It's the right solution for managing non-mergeable files. The company I work for stores just about everything in Subversion, and uses svn:needs-lock for all non-mergeable files.

I disagree with "locks are just a communication method". They are a much more effective method than push-notifications such as phone or e-mail. Subversion locks are self-documenting (who has the lock). On the other hand, if you have to communicate by other traditional push-notification channels, such as e-mail, who do you send the notification to? You don't know in advance who might want to edit the file, especially on open-source projects, unless you have a complete list of your entire development team. So those traditional communication methods aren't nearly as effective.

A central lock server, while against the principles of DVCS, is the only feasible method for non-mergeable files. As long as DVCS don't have a central lock feature, I think it will keep the company I work for using Subversion.

The better solution would be to make a merge tool for all your binary file formats, but that's a longer-term and ongoing goal that will never be "finished".

Here's an interesting read on the topic.

Answer 2

I agree that locking binary files is a necessary feature for some environments. I just had a thought about how to implement this, though:

• Have a way of marking a file as "needs-lock" (like the "svn:needs-lock" property).
• On checkout, git would mark such a file as read-only.
• A new command git-lock would contact a central lock server running somewhere to ask permission to lock.
• If the lock server grants permission, mark the file read-write.
• git-add would inform the lock server of the content hash of the locked file.
• The lock server would watch for that content hash to appear in a commit on the master repository.
• When the hash appears, release the lock.

This is very much a half-baked idea and there are potential holes everywhere. It also goes against the spirit of git, yet it can certainly be useful in some contexts.

Within a particular organisation, this sort of thing could perhaps be built using a suitable combination of script wrappers and commit hooks.