Re: Locking binary files

Daniel Barkalow [off-list ref] writes:

I think the right tool on the git side is actually a "smudge/clean" 
script. When you check something out, git converts it from the 
repository-stored form to a working tree form using a script (if there is 
one configured); this could check whether you've got the appropriate lock, 
and make the file unwritable if you don't.

An obvious question is "how would such a script check the lock when you
are 30,000 ft above ground"; in other words, this "locking mechanism"
contradicts the very nature of distributed development theme.  The best
mechanism should always be on the human side.  An SCM auguments
inter-developer communication, but it is not a _substitute_ for
communication.

But if you limit the use case to an always tightly connected environment
(aka "not distributed at all"), I agree the above would be a very
reasonable approach.

Such a setup would need a separate locking infrastructure and an end user
command that grabs the lock and when successful makes the file in the work
tree read/write.  The user butchers the contents after taking the lock,
saves, and then when running "git commit", probably the post-commit hook
would release any relevant locks.

All these can be left outside the scope of git, as they can be hooked into
git with the existing infrastructure. Once a BCP materializes it could be
added to contrib/ just like the "paranoid" update hook.