$! $!This tests the deletion of files when "revert" is run $!against them. Unfortunately this test needs to be able $!to sync a specific file out of the depot and is not $!particularly portable. In practical effect this tests $!the ability of a perforce client to effectively PURGE $!files when necessary. In order for this test to run $!there must be a P4CLIENT setup to sync a "client_file" $!out of the depot with the "perf sync" command. $! $!Alter the value of the client_file symbol to a file mapped $!to the P4CLIENT in this directory. Be sure that it is not $!synced out before this test is run. Also be sure that $!it is not of file parse type .COM so that run_all.com does not get $!confused by its presence. $! $!You will likely need to modify the client_file symbol $!here to match a suitable file in your depot: $! $ client_file = "sqlbugchk.dmp" ! change me $! $run_directory_check_status: subroutine $ client_file = p1 $ expected = p2 $ test_int = f$string(p3) $ old_mess = f$environment("MESSAGE") $ set noon $ set message /nofacility /noseverity /noidentification /notext $ directory/noout 'client_file' $ saved_status = $status $ set on $ set message 'old_mess' $ if saved_status .ne. expected $ then $ write sys$output "not ok " + test_int $ set noon $ directory/prot 'client_file' $ set on $! exit 44 $ else $ write sys$output "ok " + test_int $ endif $ exit $ endsubroutine ! run_directory_check_status $! $!Must use open/write to force a new RMS version (/append wont work) $ call run_directory_check_status 'client_file' %X10018290 1 $! $ define/user_mode sys$output nl: $ perforce sync 'client_file' $ define/user_mode sys$output nl: $ perforce edit 'client_file' $ open/write file 'client_file' $ write file "$!" $ close file $ define/user_mode sys$output nl: $ perforce revert 'client_file' $ call run_directory_check_status 'client_file' %X00000001 2 $ define/user_mode sys$output nl: $ perforce sync 'client_file'#0 $ call run_directory_check_status 'client_file' %X10018290 3 $! $ define/user_mode sys$output nl: $ newperf sync 'client_file' $ define/user_mode sys$output nl: $ newperf edit 'client_file' $ open/write file 'client_file' $ write file "$!" $ close file $ define/user_mode sys$output nl: $ newperf revert 'client_file' $ call run_directory_check_status 'client_file' %X00000001 4 $ define/user_mode sys$output nl: $ newperf sync 'client_file'#0 $ call run_directory_check_status 'client_file' %X10018290 5 $! $cleanup: $ remainder = f$search(client_file) $ if remainder .nes. "" $ then $ set security/protection=(s:rwed,o:rwed,g:rwed,w:rwed) 'remainder' $ delete/nolog/noconfirm 'remainder' $ goto cleanup $ endif
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 5686 | peter_prymmer |
VMS DCL procedures to reveal several bugs in (at least) the 2002.2 release of the p4.exe client program for VMS including: 1) use of "p4" as a foreign command global symbol is not recommended (these tests use "perforce" and "newperf") 2) the inability to deal with RMS versioning (demonstrated by the revert_deletion.com test) 3) the inability to recognize uppercase parameters and switches (demonstrated by the dash_v.com test) 4) a regression in dealing with a return() of a bad $STATUS to the command level when P4PORT is incorrectly set and you issue "perf info" (info_status.com test) I recommend reading the readme and modifying p4_setup.com and revert_deletion.com before trying to use these procedures. |