view doc/README @ 50131:e5f5f1c1c452

status: invalidate dirstate  on LockError

If we cannot take the lock, someone else is modifying the repository. Let us
discard dirstate uncommitted data before exiting the status code.

Having a clean dirstate after such operation seems safer.

Strictly speaking, there is a small behavior change in the following situation:

* process A call `status` outside of the `wlock`
* process B grab the `wlock`
* process A fails to acquires the lock to write status fixup
* process B release the `wlock` *without touching the dirstate*
* process A later grab the `wlock`
* process A can write dirstate update from earlier `status`

However this is a fairly hypothetical situation :
* process A has to be raced
* process B have to not update the dirstate
* process A has to run another *unrelated* operation later.

This seems rare enough to overlook.

I am stating that the two operations in process A has to be unrelated.
Otherwise,  collecting status data outside of the lock to use them inside the
lock is racy. Any other process could move things around (eg: the working copy)
making the data collected during status irrelevantor even harmful.

If such code exists, it should be fixed ASAP.

Mercurial's documentation is kept in reStructuredText format, which is
a simple plain text format that's easy to read and edit:

  http://docutils.sourceforge.net/rst.html

It's also convertible to a variety of other formats including standard
UNIX man page format and HTML. You'll need to install Docutils:

  http://docutils.sourceforge.net/

Use the Makefile in this directory to generate the man and HTML pages.