The introduction to Job Migration contained a few run-on sentences. This

stuff needs to be kept short and sweet.  These changes say the same things,
only in shorter sentences.  HTH.

diff --git a/docs/manual/migration.tex b/docs/manual/migration.tex
index 91e4ee774dfe19cd88846542be2aaf2cacea2ba8..22264b8d1cb7f99edc2b1df8da3728240e445c8f 100644 (file)
--- a/docs/manual/migration.tex
+++ b/docs/manual/migration.tex
@@ -4,21 +4,28 @@
 \index[general]{Migration} 
 \addcontentsline{toc}{section}{Migration}
 
-The term Migration as used in the context of Bacula means moving data from
-one Volume to another, and in particular it is a Job (similar to a backup
+The term Migration, as used in the context of Bacula, means moving data from
+one Volume to another.  In particular it refers to a Job (similar to a backup
 job) that reads data that was previously backed up to a Volume and writes
-it to another Volume purging the catalog records associated with the first
-backup job.  In other words, Migration moves Bacula Job data from one
+it to another Volume.  As part of this process, catalog records associated with the first
+backup job are purged.  In other words, Migration moves Bacula Job data from one
 Volume to another.  Although we mention Volumes to simplify the subject,
-in reality, Migration is based on moving individual Jobs from one Pool to another.
+in reality, Migration is based upon the concept of moving individual Jobs from one Pool to another.
 
 Migrations can be based on quite a number of different criteria such as:
-a single previous Job; a Volume; a Client; a regular expression matching
-a Job, Volume, or Client name; the time a Job is on a Volume; high 
-and low water marks (usage or occupation) of a Pool; Volume size, ...
+\begin{itemize} 
+\item a single previous Job
+\item a Volume
+\item a Client
+\item a regular expression matching a Job, Volume, or Client name
+\item the time a Job is on a Volume
+\item high and low water marks (usage or occupation) of a Pool
+\item Volume size
+\end{itemize}
+
 The details of these selection criteria will be defined below.
 
-To run a Migration job, you must have defined a Job resource very similar
+To run a Migration job, you must first define a Job resource very similar
 to a Backup Job but with {\bf Type = Migrate} instead of {\bf Type =
 Backup}.  One of the key points to remember is that the Pool that is 
 specified for the migration job is the only pool from which jobs will