# 
# patch "ChangeLog"
#  from [c8abb5b59ede114b87fa7de2275d908db18db297]
#    to [a5a7e41a12215c696298c98eef41ba0c62c0270e]
# 
# patch "monotone.texi"
#  from [282642c04b943449c20985b705d672098605f94d]
#    to [3c4010df98b95f235503cd19bce964957e2c74b7]
# 
--- ChangeLog
+++ ChangeLog
@@ -1,5 +1,9 @@
 2005-04-24  Nathaniel Smith  <address@hidden>
 
+	* monotone.texi (Database): Document 'db kill_rev_locally'.
+
+2005-04-24  Nathaniel Smith  <address@hidden>
+
 	* ChangeLog: Fixup after merge.
 
 2005-04-24  Nathaniel Smith  <address@hidden>
--- monotone.texi
+++ monotone.texi
@@ -4083,8 +4083,39 @@
 ensure that it is complete and consistent. The following problems are
 detected:
 
address@hidden monotone db kill_rev_locally @var{id}
+
+This command ``kills'', i.e., deletes, a given revision, as well as any
+certs attached to it.  It has an ugly name because it is a dangerous
+command; it permanently and irrecovably deletes historical information
+from your database.  There are a number of caveats:
 @itemize
address@hidden
+It can only be applied to revisions that have no descendents.  If you
+want to kill a revision that has descendents, you must kill all of the
+descendents first.
address@hidden
+It only removes the revision from your local database (hence the
+``locally'' in the command name).  If you have already pushed this
+revision out to another database, then the next time you pull from that
+database it may come back again.  There is no way to delete a revision
+from somebody else's database except to ask them to delete it for you.
address@hidden
+It does not actually delete the revision's files or manifest from your
+database.  If you run this command, and then run @command{db check}, it
+will note that you have an ``unreferenced manifest''.  If you wish to
+eliminate this data for good (and thus free up the space), you may use
+netsync to @command{pull} from your current database into a new
+database; this creates a copy of your old database, without the
+unreferenced data.  However, having this data in your database will not
+cause any problems, and acts as a safety net; if you later realize that
+you do, after all, need to retrieve the data in @var{id}, then
address@hidden check} will let you see which manifest it was, and with some
+work you can extract @var{id}'s data.
address@hidden itemize
 
address@hidden
+
 @item missing files 
 that are referenced by their @sc{sha1} hash from some manifest but do not
 exist in the database.  This is a serious problem; it means that your