Re: Locking binary files

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Sep 23, 2008, 17:32 UTC
Message-ID: <alpine.LNX.1.00.0809231216350.19665@iabervon.org>
In-Reply-To: <94c1db200809230656q4a9a765dw2354c0058b1d940c@mail.gmail.com>

On Tue, 23 Sep 2008, Mario Pareja wrote:

Show 17 quoted lines

> > So it's a communication issue then.
> 
> Yes, but I think the communication of this information needs to happen
> as part of a developers normal work-flow rather than requiring them to
> remember to check an external system.
> 
> > The way I understand locks in svn
> > and cvs is that they also only bother you when you want to check in the
> > file you've just recently modified, or if multiple people want to lock
> > the same file at the same time.
> 
> The SVN client will make locked files read-only until a lock is
> obtained for them.  This helps "remind" you that a lock should be
> obtained before editing such a file. Requiring the developer to obtain
> a lock ensures that nobody else is editing the file and prevents
> wasted work.  Upon commit, the file is marked as unlocked and the
> local file is once again read-only.

I think the right tool on the git side is actually a "smudge/clean" script. When you check something out, git converts it from the repository-stored form to a working tree form using a script (if there is one configured); this could check whether you've got the appropriate lock, and make the file unwritable if you don't. Then you have a script that gets or releases a lock and sets any write bits on files already checked out appropriately. There could also be locking-server magic to detect that you've pushed a change and release the lock, telling you so that it makes your file unwritable, but that's optional.

(Side note: consider version-specific logos; which lock you need depends on which version you're working on, and you may want to pick up locks for multiple versions and make changes to each logo, switching between the branches, and make sure you can get all the locks before you start working on any of the files, despite not having any individual file checked out continuously in the process)

Show 8 quoted lines

> > Note that locking would be completely advisory though, and nothing
> > would prevent people from committing changes to a locked file.
> 
> If git were to support locking then it could prevent people from
> committing without first locking.  Even if it is not supported
> directly by git - perhaps using a lock daemon - a wrapper would need
> to be written around git commit/push to prevent developers from
> committing/pushing changes that would cause binary merging conflicts.

If you've gotten to the point of committing (let alone pushing), and you haven't got exclusive access, git should certainly not prevent you; the point of the locking is to prevent people from doing work that will be wasted, and the work is already done at this point. It's better then to actually try the binary merge, which comes down to apologizing profusely and then somebody openning the 3 versions (theirs, the other side's, and the common ancestor) in their graphics program and modifying the other side's to include their change. It wouldn't help anything to prevent people from being able to get all of these versions to each other, once they're made. It's also helpful to have people commit what they did before redoing it, so that they can use it for reference in the process and won't lose it.

(Actually, I bet it would be not-too-hard to set up gimp for three-way merge of images; open the result file with "theirs" as the contents, and open the common ancestor and "yours" as extra layers and set the ancestor to negative, and make the user clean up the mess)

On the other hand, the locking server should reject your push if somebody else has got the lock, so that the person who editted the file without having the lock is the one stuck redoing things.

In any case, the fundamental idea is: (a) you want some server to favor people who declare their intent to change something in advance, and give all the work of redoing stuff to people who didn't declare their intent in advance; and (b) you want to prompt people to declare their intent in case they forget.

(a) is a pre-update hook that checks the diffstat against other people's locks. (b) is a smudge script that makes files you're supposed to lock and haven't a-w. Of course, git doesn't have the code for manipulating a per-user set of locks, but it shouldn't be too hard to find some project that just does that.

	-Daniel
*This .sig left intentionally blank*