On Tue, Sep 23, 2008 at 02:39:41AM -0400, Mario Pareja wrote: > > How else can one developer be sure that time spent editing a > binary file will not be wasted because another developer submitted a > change? That sounds to me more like a communication problem than anything related to Git itself. > > 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? The problem exists regardless the distributed nature of git. Let's consider a single repository with only two branches: A and B. Now, one developer has decided to edit some binary file called pretty.img on A. Should this file be locked only on the branch A or on both branches? The answer is if A is going to merge to B then this file on B too and remain locking till A is merged to B. In fact, it may be *absolutely* pointless to lock the file on the developer's topic branch, because another developer can edit it on another topic branch without noticing that this lock exists at all. So, it may be enough to lock it only B enough, but this is impossible to Git to know, because Git does not understand _your_ particular workflow, and without any locking scheme is rather meaningless. Perhaps, a more general solution can be based exactly on the content, not on the name, i.e. in some share directory on the server I create a file with name based on SHA-1 of the binary file where I put comment explaining why I locked it. Obviously, this lock is purely advisory, but it is good, in some situation you really may want to edit two files with the same SHA-1 on different branches that never get merge. Moreover, this lock is never deleted. So, it could make sense instead of having a separate file per lock to organize it in some more compact storage, which may look like history of editing binary files... But it is just an idea how I would do that. Dmitry -- 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
