communicating expectations of whether a binary file may be edited

[arghman]

Note the lack of the word "locking" in the subject. :-)

I am working with a coworker on a project and we have been trying out
Mercurial for a while, having the "master" repository living on a network
fileserver, and using push/pull from our local clones of the repository to
keep in sync.

It's been all great except for one instance where we have an Excel file
(don't ask!) that I edited while he was editing it, and we spent several
hours trying to manually merge our changes together. Of course we wish to
avoid this scenario again. He is suggesting that if we can't find a viable
solution, we should no longer use Mercurial, and that SVN prevents this case
since it allows for advisory locks on the use of binary files.

I've looked around on the mailing list and found a few contentious threads
about file locking and Hg (notably
http://www.nabble.com/File-Locking-td19861371i20.html ) and was just
wondering what the current state-of-thinking was on the subject, and how I
can get some kind of simple mechanism in place to significantly reduce the
chance of simultaneously editing binary files when Mercurial is used with a
known central or "master" repository, by a small number (< 10) of
developers.

Here's what comes to mind; I have no experience in Python so writing my own
extension is essentially out.

1) Don't do it (simultaneously edit the binary file) -- not a viable option.
We are both rather error-prone.

2) Use an out-of-band technique, e.g. email, to communicate whether a file
may be edited -- not a viable option. We are both rather error-prone, and
besides, this breaks down for more than a handful of binary files

3) Store our binary files in a centralized repository e.g. SVN -- not a
viable option, this splits a source tree unnecessarily and is a potential
source of error to maintain one source tree with two systems.

4) Store everything in a centralized repository e.g. SVN -- a possibility.

5) Somehow associate each of our local Hg repositories + their hooks, with a
centralized "protection" mechanism (outside Mercurial, for brevity's sake I
am abbreviating as CPM) for recording status bits of files that are in need
of protection against simultaneous editing: add some kind of hook that on
checkout ("hg update"?) looks at the CPM mechanism to apply read-only status
to files that are being "protected". Seems simple -- in order to edit a
file, you need to change the status bits in the CPM, and do an "hg update",
applying writable status only to files that have the right bits in the CPM
(hook would have to compare local and centralized Hg repositories, make sure
they're at the same revision, then allow the files in question to be
writeable). Or you can break the normal workflow and then you're running at
your own risk.

I know enough about databases and webservers to implement a CPM pretty
easily, and of course it's easy to change the filesystem's read-only bit,
and hooks look like they can run arbitrary programs, so it looks like it
should be possible to pull something together -- but I have no idea if I've
missed something subtle here.

6) Have something else (???) that works within Mercurial itself.

any ideas? As we need to get something working soon in our group, I am less
interested in how Mercurial should work as a default, then how this kind of
functionality can be made to work reliably.
-- 
View this message in context: http://www.nabble.com/communicating-expectations-of-whether-a-binary-file-may-be-edited-tp23768475p23768475.html
Sent from the Mercurial mailing list archive at Nabble.com.