Rev 20: Add a README trying to define the general use of the plugin. in lp:~jameinel/+junk/file_locking

[John Arbash Meinel]

At lp:~jameinel/+junk/file_locking

------------------------------------------------------------
revno: 20
revision-id: john at arbash-meinel.com-20090921195731-zjkgx23omnlaxnth
parent: john at arbash-meinel.com-20090921194240-n7sds4f97u0cnh8t
committer: John Arbash Meinel <john at arbash-meinel.com>
branch nick: file_locking
timestamp: Mon 2009-09-21 14:57:31 -0500
message:
  Add a README trying to define the general use of the plugin.
-------------- next part --------------
=== added file 'README.txt'
--- a/README.txt	1970-01-01 00:00:00 +0000
+++ b/README.txt	2009-09-21 19:57:31 +0000
@@ -0,0 +1,38 @@
+##########################
+Bazaar File Locking Plugin
+##########################
+
+This implements some basic support for tracking locks that effect individual
+files. This is meant to assist groups that have some files that do not merge
+well. The idea is that you can take out a lock on that file, to indicate to
+other people that they shouldn't modify it.
+
+These locks are meant to be advisory. In a distributed world, you can't prevent
+someone from committing what they want. Even further, though, is that you can't
+keep someone from updating the file without committing that change. The idea is
+to just help users coordinate.
+
+
+Overview
+~~~~~~~~
+
+The basics for this plugin are that the user sets up a central location where
+the locking information will be shared. With that set up, users set a
+configuration setting to point to that location for all branches that should be
+effected. This way even someone working on a feature branch can take out a
+lock against someone else working directly on trunk.
+
+Specific files/directories are then added to the 'tracked' set. One can also
+think of this as lock-points. This is another aid that lets you clearly define
+where things should be locked. This way, we can inform a user if they are
+modifying something that should be locked, and ensure that some people don't
+lock a dir and some lock a single file. [1]_
+
+.. [1] TODO: if we read all the currently active locks all the time, maybe the
+       extra 'tracking' is not worthwhile? Though we still get the assistance
+       of recommended lock points...
+
+
+.. 
+   vim: ft=rst tw=79
+