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 -- 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
