Subject: Re: Locking binary files

From: Boaz Harrosh <[email-masked]>
Date: Tue, 23 Sep 2008 14:20:16 +0300

Boaz Harrosh wrote:
> Mario Pareja wrote:
>> 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
> 

OK combine that with a technic presented in this ml thread:
  "Management of opendocument (openoffice.org) files in git" 
And make all this automatic for particular type of files

Boaz