t98xx: fix Perforce tests with p4d r23 and newer

Some of the tests in t98xx modify the Perforce depot in ways that the
tool wouldn't normally allow. This is done to test behaviour of git-p4
in certain edge cases that we have observed in the wild, but which
should in theory not be possible.

Naturally, modifying the depot on disk directly is quite intimate with
the tool and thus prone to breakage when Perforce updates the way that
data is stored. And indeed, those tests are broken nowadays with r23 of
Perforce. While a file revision was previously stored as a plain file
"depot/file,v", it is now stored in a directory "depot/file,d" with
compression.

Adapt those tests to handle both old- and new-style depot layouts.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/t9825-git-p4-handle-utf16-without-bom.sh

@@ -22,9 +22,25 @@ test_expect_success 'init depot with UTF-16 encoded file and artificially remove
 		cd db &&
 		p4d -jc &&
 		# P4D automatically adds a BOM. Remove it here to make the file invalid.
-		sed -e "\$d" depot/file1,v >depot/file1,v.new &&
-		mv depot/file1,v.new depot/file1,v &&
-		printf "@$UTF16@" >>depot/file1,v &&
+		#
+		# Note that newer Perforce versions started to store files
+		# compressed in directories. The case statement handles both
+		# old and new layout.
+		case "$(echo depot/file1*)" in
+		depot/file1,v)
+			sed -e "\$d" depot/file1,v >depot/file1,v.new &&
+			mv depot/file1,v.new depot/file1,v &&
+			printf "@$UTF16@" >>depot/file1,v;;
+		depot/file1,d)
+			path="$(echo depot/file1,d/*.gz)" &&
+			gunzip -c "$path" >"$path.unzipped" &&
+			sed -e "\$d" "$path.unzipped" >"$path.new" &&
+			printf "$UTF16" >>"$path.new" &&
+			gzip -c "$path.new" >"$path" &&
+			rm "$path.unzipped" "$path.new";;
+		*)
+			BUG "unhandled p4d layout";;
+		esac &&
 		p4d -jrF checkpoint.1
 	)
 '