Re: Locking binary files

On Wed, 24 Sep 2008, Dmitry Potapov wrote:

On Tue, Sep 23, 2008 at 05:13:29PM -0400, Daniel Barkalow wrote:

quoted

The lock needs to last until you push to the repository the lock is for; 
otherwise you have the exclusive ability to make changes, but someone who 
grabs the lock right after you release it will still be working on the 
version without your change, which is what the lock is supposed to 
prevent.

It still will happen if developers work on topic branches, and it is not
a rate situation with Git. Thus locking some particular path is stupid.
What you may want instead is too mark SHA-1 of this file as being edited
and later maybe as being replaced with another one. In this case, anyone
who has the access to the central information storage will get warning
about attempt to edit a file that is edited or already replaced with a
new version.

No, your goal is to avoid having to do a merge in order to do a particular 
push. That push is the push to the shared location. It doesn't matter if 
you use topic branches, because your eventual goal is still to push to the 
shared location (or, possibly, to have the project maintainer push to the 
shared location with some sort of interesting delegation), so you lock the 
shared location, not your topic branch.

On the other hand, it's easily possible that other people (or you) want to 
fork the image, such that only some locations (either different paths in 
the project or the same path in different branches) get your change and 
other branches get different changes made at the same time. Of course, if 
you want to change multiple things, you need to get multiple locks.

	-Daniel
*This .sig left intentionally blank*