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?
Because they will cause merge conflicts when you try to bring the histories together. Some binary formats can be edited by multiple users at the same time, while others can't, so git will try to merge those binary files for you. For images, that almost certainly won't go so well so it will result in a conflict.
To achieve the effects of locking, a "central" repository must be identified.
To achieve distributedness no central repository must exist. Locking can be done by some other means.
Regardless of the distributed nature of git, most _companies_ will have a "central" repository for a software project.
Actually, all projects with some sort of userbase will probably have some official "here's the published code suitable for production use" repository. To say that it's the "central" one is a bit off though. It's merely a public place that can be referred to for convenience.
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!
Try and find out. mkdir foo && cd foo && git init cp /random/binary/file.png image.png git add image.png && git commit -m"first commit" git checkout -b A cp /other/random/binary/file.png image.png git add image.png && git commit -m"conflicting commit" git checkout -b B master cp /third/random/binary/file.png image.png git add image.png && git commit -m"non-conflicting commit" git checkout master cp /third/random/binary/file.png image.png git add image.png && git commit -m"master says 'so be it'" git merge B; # works, since the binary files are the same git merge A; # produces a conflict message In which way is that not exactly the right behaviour? How would locking have helped? If your colleagues are replacing files you committed so that your code suddenly fails, you have a communication (and QA) issue at work. Adding locking to git is not the solution to that problem. Introducing a sort of builtin notion of a central repository is, frankly, disgusting. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- 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
