USAGE for fix_ktext_only.sh v1.2.0:

fix_ktext_only.sh <P4VerifyLog> [-L <log>] [-n] [-d|-D]

or

fix_ktext_only.sh [-h|-man]


DESCRIPTION:
	This script process a log from the p4verify.sh script
	containing errors suspected to be mere kxtext errors.

	The call to p4verify.sh script looks something like this:
	nohup p4verify.sh -paths /p4/common/site/cvsfix/PathsToTarget.txt -dlf /p4/common/site/cvsfix/DepotListFile.txt -nS -L /p4/1/logs/p4verify.cvsfix.fresh_sandbox.$(date +'%Y-%m-%d-%H%M%S').log -d < /dev/null > /dev/null 2>&1 &

	The p4verify.cvsfix.fresh_sandbox.<timestamp>.log file is then fed to
	this script, which is executed like so:
	nohup ./fix_ktext_only.sh /p4/1/logs/p4verify.cvsfix.fresh_sandbox.<timestamp>.log < /dev/null > /p4/1/logs/cvsfix/fko.log 2>&1 &

	This scripts then fixes such errors just by recalculating
	the expected checksum with 'p4 verify -v' commands.

	The pattern deemed to be mere ktext errors have this profile:
	* Files fail to verify cleanly on the sandbox commit server,
	even though all files in target paths are known to verify
	cleanly on the production commit server.
	* Files types include the '+k' filetype modifier.
	* The verify error type is 'BAD' (not 'MISSING').

	This script is intended to be called twice. The first run will
	fix errors, and the second run should detect that all files are
	already OK.

OPTIONS:
 <P4VerifyLog>
 	Specify the path to a log file from p4verify.sh that was
	executed on the edge server, and which contains suspected
	CVS import failures.

 -L <log>
	Specify the path to a log file, or the special value 'off' to disable
	logging.  By default, all output (stdout and stderr) goes to:

	/tmp/cvsfix/fix_ktext_only.<DateStamp>.log

	The [.NN.RandomNumber] are used only if needed, if this script is
	called more than once per second.

	NOTE: This script is self-logging.  That is, output displayed on the screen
	is simultaneously captured in the log file.  Using redirection operators like
	'>' or '2>&1' are optional, as is using tee.

 -n	Enable No-Op (No Operation).  Commands that that significantly affect data
	are displayed rather than executed.  This is useful for performing dry runs.

 -d     Debug mode, enables additional output.

 -D     Set extreme debugging verbosity.

HELP OPTIONS:
 -h	Display short help message with synopsis of command line usage.
 -man	Display full manual-style help message (this page).

SETUP:
	In an SDP environmet, create the /p4/common/site/cvsfix directory,
	and deploy this script fix_ktext_only.sh in that folder, making
	sure the +x execution bit is set on the file.

EXAMPLES:
	EXAMPLE 1: Targeted

	In this example, our goal is to fix ktext files only in paths
	//abc/dev/... and "//xyz/import/code/my files/...".

	This examples targets ktext errors in certain folders, using a
	targeted call to p4verify.sh.

	First, create a file DepotListFile.txt to contain depots to be
	processed, as the OS user that owns /p4/common, like so:

	cd /p4/common/site/cvsfix

	echo abc > /p4/common/site/cvsfix/DepotListFile.txt
	echo xyz >> /p4/common/site/cvsfix/DepotListFile.txt

	Next, create a file PathsToTarget.txt to contain the specific paths
	to be processed within that depot (noting handling of a path with
	spaces), like so: 
	echo //abc/dev/... > /p4/common/site/cvsfix/PathsToTarget.txt
	echo "//xyz/import/code/my files/..." >> /p4/common/site/cvsfix/PathsToTarget.txt

	Next, call the targeted p4verify.sh script like so:

	nohup p4verify.sh -paths /p4/common/site/cvsfix/PathsToTarget.txt -dlf /p4/common/site/cvsfix/DepotListFile.txt -nS -L /p4/1/logs/p4verify.cvsfix.fix_ktext.log -d < /dev/null > /dev/null 2>&1 &

	Monitor the log: /p4/1/logs/p4verify.cvsfix.fix_ktext.log

	When that finishes (it may take a long while), call this script as a dry run:
	nohup ./fix_ktext_only.sh -n -d /p4/1/logs/p4verify.cvsfix.fix_ktext.log < /dev/null > $LOGS/fix_ktext_only.dry_run.log 2>&1 &

	Wait for that to complete, and then review the log: $LOGS/fix_ktext_only.dry_run.log

	If that looks good, proceed:
	nohup ./fix_ktext_only.sh /p4/1/logs/p4verify.cvsfix.fix_ktext.log < /dev/null > $LOGS/fix_ktext_only.live_run.log 2>&1 &

	Wait for that to complete, and then review the log: $LOGS/fix_ktext_only.live_run.log

	EXAMPLE 2: Fix all ktext file issues that we can.

	In this example, we use a call to p4verify.sh that skips shelves but is otherwise
	complete:

	nohup p4verify.sh -nS -L /p4/1/logs/p4verify.cvsfix.fix_ktext.log -d < /dev/null > /dev/null 2>&1 &

	Monitor the log: /p4/1/logs/p4verify.cvsfix.fix_ktext.log

	When that finishes (it may take a long while), call this script as a dry run:
	nohup ./fix_ktext_only.sh -n -d /p4/1/logs/p4verify.cvsfix.fix_ktext.log < /dev/null > $LOGS/fix_ktext_only.dry_run.log 2>&1 &

	Wait for that to complete, and then review the log: $LOGS/fix_ktext_only.dry_run.log

	If that looks good, proceed:
	nohup ./fix_ktext_only.sh /p4/1/logs/p4verify.cvsfix.fix_ktext.log < /dev/null > $LOGS/fix_ktext_only.live_run.log 2>&1 &

	TIP:  Even if your intent is to fix all ktext issues, if you know from prior runs of
	p4verify.sh where the errors are, you can save time by targeting the p4verify.sh script
	to the known locations of verify errors, using the targeting method illustrated in
	EXAMPL1.

	TIP: If you have a prior p4verify.sh generated from the normal weekly SDP crontab
	call to p4verify.sh, that may contain shelved file errors that will confuse this
	script. If you can confirm from the summary that there are no errors, then you can
	use this script and feed it that previously generaeted log that is free of shelved
	file errors. This will save the step of doing a separate run of p4verify.sh.  If
	there are any shelved errors in the weekly log, then do the procedure as noted
	above, calling 'p4verify.sh' with the '-nS' (no shelves) option.