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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
