Re: Locking binary files

On Wed, Sep 24, 2008 at 12:15:39AM -0400, Daniel Barkalow wrote:

On Wed, 24 Sep 2008, Dmitry Potapov wrote:

quoted

What are you saying is that when I am locking some file on the current
branch, Git (or whatever script that performs this locking) should figure
out what is the original shared branch for it and lock the file there.

Or you should have to say. But "git lock <filename>" should probably 
put the lock on whatever branch "git push" would push to, and similarly 
for the other argument combinations that "git push" permits.

It seems to me very fragile to rely on the push configuration in deciding
what can be locked and what cannot. Besides this configuration can change
over time. So what is going to happen with locks then? Another problem:
what if I don't push anyway but usually send pull-requests?

The fact is if you cannot get your locking working in _one_ repository
then any hope that it will work when you have more than one is nothing
but a pipe dream.

quoted

Maybe, it can work, but it sounds too complex to me. I believe that my
idea using SHA-1 is better. After all, what is file? It is its content.
At least, in Git, we always identify files by their content.

Not at all; there are plenty of cases where what matters is the path, and 
some things are relevant by virtue of the form of the filename which names 
that content.

Whether it matters or not depends on a particular workflow and what the
developer wants to achieve. Such decisions should be taken by human
being, otherwise you are prone to do the wrong things too often.

quoted

Thus if you lock some file, you put a lock on certain SHA-1. Now, 
regardless of branches and paths, this lock can work provided that you 
have access to some shared location. Of course, this lock is purely 
advisory, but it is good, because you may want to ignore it in some 
case.

In my design, the lock (on the shared repository) is not advisory; if 
someone else has it, you can't push if the new commit doesn't match the 
old commit for that path.

Hey, if someone wants to push this file, it means it is already late,
because you _already_ have the situation where two people have edited
exactly the same binary file. Isn't the situation that the lock was
intended to prevent?

So, the goal should be to warn someone who is going to edit file locked
by someone else. You cannot prevent him/her from doing so, only to warn
about that.

As to pushing, it can be different policies. IMHO, the update hook is
the best place to express what push you want to allow and what not, but
some workflow may not use push at all, yet ability to lock (perhaps,
'synchronize' would be a better word here) may still be needed.


Dmitry