communicating expectations of whether a binary file may be edited

[Felix -]

here's a possible scheme using just existing behavior:

designate a push-able repo as a rendezvous point.
whenever you want to edit a binary file $f
  hg pull -u
  ln -s "reserve:$myname" $f.reserve
  hg add $f.reserve
  hg ci -m "reserve $f"
  hg push

when you're done editing $f:
  hg rm $f.reserve
  hg ci -m "unreserve $f"
  hg push

if you try to reserve when someone else has,
then you'll get a complaint at some step.
either "ln -s" will say $f.reserve already exists,
or "hg push" will say creating new head.

at that point, simplest thing to do is to
resolve the conflict in favor of other,
and try again when the reserve is gone.

the reason $f.reserve is a symlink instead
of a file is so that it never accidentally
gets automatically merged.  if you need
to interoperate with windows, using a
plaintext file might be ok, with some
additional checking.

to guard against accidentally editing a
file without reserving it, maybe use a wrapper
around hg that checks for .reserve files
after an update, and adjusts read-only bits.

this scheme doesn't help if a binary file
gets conflicting edits on branches that
are intended to be merged later.
I'm not sure what to do for that.

On Thu, May 28, 2009 at 12:30 PM, arghman <jmsachs at gmail.com> wrote:
>
> 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.
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>