Explore using -ztag for output processing

[HakShak]

https://www.perforce.com/manuals/v18.1/cmdref/Content/CmdRef/global.options.html under "-z tag"

λ p4 -ztag changes -m 1 //eve/branches/development/MAINLINE/...
... change 1867011
... time 1610707820
... user eve_automation
... client TC_p4_Windows_Server_2019_i_03871561973cf6481_257020e0128b58e3_80da8d9f1ea76dac
... status submitted
... changeType public
... path //eve/branches/development/MAINLINE/eve/autobuild/staticDataLoaders/...
... desc [eve MAINLINE] Automatic static

[polarina]

@HakShak Hi. I remember you suggested ztags a long time ago while I was writing this library. I decided against it since ztags are grammatically ambiguous in p4 while at the same time the ordinary standard output is not, ironically.

In particular, changelist descriptions that contain lines beginning with ... are problematic and cannot be unambiguously parsed with ztags.

[polarina]

Ztag parsing, including tests, was previously implemented in commits ef875d8 and b284784, subsequently removed in 535d329.

[HakShak]

Mobile at the moment, but descriptions doesn't seem to be a good enough reason. Was there anything else to throw away a major global option of the entire ecosystem in favor of output that has no purpose to maintain comparability?

[polarina]

No, descriptions are the only known problem.

Keep in mind that there are already existing changelists in CCP's Perforce that contain lines beginning with three dots -- the parser I referenced above will either not accept those or parse the changelist incorrectly (depending on what is on the line after the dots) and it was causing issues.

I was not able to devise a parser that could deal with those existing changelists in a manner less cumbersome than the regular expressions that we have now.

If the only issue were that we wouldn't get the description out correctly, it might be tolerable. However, the p4 command we run will spew out multiple changelists to standard output. The three dots in changelist descriptions make it difficult do delimit when one changelist ends and the next starts.

[HakShak]

Wouldn't ... <token> be enough to distinguish those on top of newlines?

[polarina]

Wouldn't ... be enough to distinguish those on top of newlines?

Well, no, not if a changelist's description contains a line of the form ... <token> itself.

Supposedly, some heuristics could be applied to disambiguate many cases but it cannot be foolproof. It is quite trivial to maliciously craft a single changelist that will be printed by p4, with ztag, byte-for-byte identically to what could've been two ordinary changelists.