# 
# patch "ChangeLog"
#  from [6e22e889153a1f364903affbebb2740b5c88ce12]
#    to [5f22b15b8800a0c76f3b0e4b26ecda1cb7f654ca]
# 
# patch "monotone.texi"
#  from [46a721660c81dc2ff3db7ad2dc211accb2f04475]
#    to [4d4c00faec3b836fe34b711702de0f1e8368645b]
# 
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,8 @@
+2005-04-26  Matt Johnston  <address@hidden>
+
+	* monotone.texi: fix mashed up merge of docs for kill_rev_locally
+	and db check.
+
 2005-04-25  Nathaniel Smith  <address@hidden>
 
 	* automate.cc (automate_parents, automate_children) 
--- monotone.texi
+++ monotone.texi
@@ -4139,39 +4139,8 @@
 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
@@ -4284,20 +4253,39 @@
 
 @end itemize
 
-This command also verifies that the @sc{sha1} of every file, manifest,
+This command also verifies that the @sc{sha1} hash of every file, manifest,
 and revision is correct.
 
address@hidden monotone db kill_rev_locally @var{rev1}
address@hidden monotone db kill_rev_locally @var{id}
 
-This will simply delete a revision with revision id @var{rev1} from your
-local database.  If you already synchronized with another database this
-command is senseless, as it will come back to you.  It might leave some
-unreferenced 'manifest ids' and 'file deltas' in your database which is
-non-fatal but annoying.  Generally, this is not the preferred way of
-doing things, you might want to use @var{disapprove} to undo changes
-instead. @var{kill_rev_locally} basically belongs in the category of
-useful but
address@hidden''-category.
+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:
address@hidden
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
 
 @item monotone db execute @var{sql-statement}