Re: Locking binary files

From: Boaz Harrosh <bharrosh@panasas.com>
Date: Sep 23, 2008, 11:16 UTC
Message-ID: <48D8CFF1.8030403@panasas.com>
In-Reply-To: <94c1db200809222339t7d65081eq7471fef86fb5ec73@mail.gmail.com>

Mario Pareja wrote:

Show 31 quoted lines

> Hi,
> 
> 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 think we need to come
> up with some workarounds.  For Linux kernel development this is may
> not be an issue; however, for application development this is a major
> issue. How else can one developer be sure that time spent editing a
> binary file will not be wasted because another developer submitted a
> change?
> 
> 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.  Is this made
> difficult because git tracks file contents not files?
> 
> In any case, I think this is a crucial issue that needs to be
> addressed if git is going to be adopted by companies with binary file
> conflict potential. I don't see how a web development company can take
> advantage of git to track source code and image file changes.  Any
> advice would be great!
> 
> Regards,
> 
> Mario
> --

It should be easy for a company to set a policy where a couple of scripts must be run for particular type of files. Given that, the implementation of such scripts is easy:

For every foo.bin there is possibly a foo.bin.lock file.

Lock-script look for absence of the lock-file at upstream then git-add the file (With some info that tells users things like who has the file). If git-push fails, since I'm adding a file and someone already added it while I was pushing, then the lock is not granted.

Unlock-script will git-rm the lock-file and push.

In both scripts mod-bits of original file can be toggled for read-only/write signaling to the user. (At upstream the file is always read-only)

This can also work in a distributed system with more then one tier of servers. (Locks pushed to the most upstream server)

Combine that with git's mail notifications for commits and you have a system far more robust then svn will ever want to be

My $0.017 Boaz