Show 59 quoted lines
> 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
>