Re: Locking binary files

["Mario Pareja" <mpareja.dev@gmail.com>]

> 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.

>
> 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.

> Then
> again, insofar as I understand SVN/CVS locking, that's how those
> work too, except that an SVN "checkin" would be the equivalent of
> "git commit && git push" (the push part of the git sequence won't
> work).
>

Generally in SVN you need to lock the file before being able to commit.

Really, I am just curious about how others deal with this issue.  Do
you simply start editing binary files and hope nobody else edits the
same file?  Do you send out an email telling people you are working on
such a file?

Mario