Re: Locking binary files
- From
Andreas Ericsson <ae@op5.se>
- Date
- Sep 23, 2008, 07:18 UTC
- Message-ID
- <48D8983C.7070506@op5.se>
- In-Reply-To
- <94c1db200809222339t7d65081eq7471fef86fb5ec73@mail.gmail.com>
Mario Pareja wrote:
Show 14 quoted lines
> 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.
Show 10 quoted lines
> 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@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231