#
#
# patch "monotone.texi"
#  from [cd6cea7c23cebeb04d78d0a7cde5817c313b0729]
#    to [83908db6b19b262c96f4383fd23075ab21c06329]
#
============================================================
--- monotone.texi	cd6cea7c23cebeb04d78d0a7cde5817c313b0729
+++ monotone.texi	83908db6b19b262c96f4383fd23075ab21c06329
@@ -6529,11 +6529,11 @@ @section Database
 database to create a manifest data packet, which can be loaded into your
 database with @command{read}.
 
address@hidden unreferenced manifests
address@hidden unreferenced rosters
 that exist in the database but are not referenced by their @sc{sha1}
 hash from any existing revision.  In itself, this only indicates some
 wasted space, and is not a problem; it's possible it could arise under
-normal use (for instance, if you have run @command{db kill_rev_locally},
+normal use (for instance, if you have run @command{local kill_revision},
 or in some strange-but-harmless corner cases following an incomplete
 netsync).  It could also arise, though, as a symptom of some other more
 serious problem.
@@ -6628,10 +6628,10 @@ @section Database
 This command also verifies that the @sc{sha1} hash of every file, manifest,
 and revision is correct.
 
address@hidden mtn db kill_rev_locally @var{id}
address@hidden mtn local kill_revision @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
+certs attached to it.  It is a very dangerous
 command; it permanently and irrevocably deletes historical information
 from your database.  If you execute this command in a workspace, whose
 parent revision is the one you are about to delete, the killed revision
@@ -6647,14 +6647,14 @@ @section Database
 descendants first.
 @item
 It only removes the revision from your local database (hence the
-``locally'' in the command name).  If you have already pushed this
+``local'' 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.
 @item
 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
+will note that you have an ``unreferenced roster''.  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
@@ -6665,17 +6665,23 @@ @section Database
 work you can extract @var{id}'s data.
 @end itemize
 
address@hidden mtn db kill_certs_locally @var{selector} @var{certname} @var{[certval]}
address@hidden mtn local kill_certs @var{selector} @var{certname} @var{[certval]}
 
 This command deletes certs with the given name on revisions that match
 the given selector. If a value is given, it restricts itself to only
-delete certs that also have that same value.
-
-This only deletes the certs from your local database; if there are
-other databases that you sync with which have this tag, the tag certificates
+delete certs that also have that same value. Like @command{kill_revision},
+it is a very dangerous command; it permanently and irrevocably deletes
+historical information from your database. Also like @command{kill_revision},
+this only deletes the certs from your local database; if there are
+other databases that you sync with which have these certs they
 will reappear when you sync, unless the owners of those databases also delete
 those certificates locally.
 
+Early versions of monotone had @command{db kill_tag_locally} and
address@hidden kill_branch_certs_locally} commands. These can be emulated with
address@hidden kill_certs i: tag TAG} and
address@hidden kill_certs i: branch BRANCH}, respectively.
+
 @item mtn db execute @var{sql-statement}
 
 This is a debugging command which executes @var{sql-statement} against