Uses a distributed lock on git handler to avoid race condition

[mgaitan]

a concurrent edition in a page can leave the repo in a dirty state like the following:

facundo@web:/home/www-pyar/pyarweb/pyarweb/waliki_data$ git status
HEAD detached from cd73ae5
Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        both modified:   PyCamp/OrganizandoUnPyCamp.rst

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   mi.rst

no changes added to commit (use "git add" and/or "git commit -a")

Explanation

the simplistic apprach of waliki uses system calls to the "git command". this process imply few commands (branch, commit, merge). If a second edition (on any page) is saved before a previous one finish, those git commands could be mixed

solution

we need to lock, at least the "Git.commit" method. Research the proper lib to use https://pypi.python.org/pypi?%3Aaction=search&term=distributed+lock&submit=search

[mgaitan]

this seems to be simple enough https://pypi.python.org/pypi/pylock/0.3

[wagnerflo]

From my reading of pylock's documentation this package seems a bad choice. Anyone deploying a Waliki based website will then have to decide between:

1. Increased effort for installing and maintaining either Redis or Memcache.
2. Selecting the "Open (non-locking) backend" and gaining no improvement while still inheriting the increased complexity in Waliki code as well as more dependencies.

A distributed locking library that has a "fallback" to file locks for simple and small installations would be very much preferable IMO.