The Operations / SysAdmin guy that I work with, Zandr, reported that a darcs
push failed because he didn't have write access to create the lock file.  This
is understandable, and apparently the error message was clear enough, but this
later caused me to wonder -- why does darcs push require a lock in the source repo?

And for that matter, why does it require write access to anything in the source
repo?

To be clear the failure that Zandr encountered was that he didn't have write
access to the *local* repo, the one *from* which he was pushing.

Was Zandr using darcs-1? And what format repository was he using?

If he was using darcs-2 and a hashed-format repository, this is definitely a bug
(albeit a mild one).

If he was using darcs-1, then this is a known issue that I believe is fixed when
using hashed formats.

If he was using darcs-2 on a non-hashed repository, then this is correct
behavior--and a reason to use a hashed format.  The reason is that with
old-format repositories, a change to the repository while reading it could lead
to the reading of a corrupt version, which would be very, very bad.  This can't
happen with hashed repositories, though, which are more atomic.

I couldn't swear to the original instance being darcs2 and hashed-format, but we
just hit it again on a hashed repo.

This is a duplicate of the later issue855

I disagree that this is a duplicate of 855. Or, at least that the fix for 855
(which special cases --dry-run) is a fix for this.

We just hit this again, trying to push from a darcs2/hashed repo to another one
on a different box. I really want to be able to run scripts that keep repos in
sync under a user that doesn't have write permission to the source repo.