Posted 30 May 2020 - 01:36 PM
Here's the background of the question, which is important to understanding it. My work involves editing documents stored in Perforce from drafts submitted by other people. Someone copies the latest revision and makes changes, then sends their draft to me. I compare it to the original to find the changes they made and edit the original accordingly. But if one or more revisions have been submitted since the other person made their copy, it becomes very difficult to tell which differences reflect changes they made in their draft, and which represent changes made later in the depot. I want a simple, reliable way to tell what revision they started with, so I can compare their draft to that revision and get an accurate diff.
Posted 30 May 2020 - 02:30 PM
Posted 01 June 2020 - 05:22 PM
If I interpreted it correctly, I can put a tag like $Revision$ in a file (or $Revision:$; different pages say both), and when I submit the file Perforce will expand the tag to $Revision: 3$ or whatever. Then when I retrieve the file I can see that value. If I submit it again, $Revision: 3$ is replaced with $Revision: 4$.
But this assumes that Perforce knows how to read and modify a Word document file. Does it? According to the stuff I found, Perforce will recognize a Word document file as a .zip file and assign it a filetype of ubinary. If that's all there is to it, the whole concept must inapplicable; knowing that a file is ubinary, or even known that it's a .zip file, doesn't tell Perforce how to read or change the content. Perforce would have to recognize the file as a Word document file to do that. Perhaps it does, but I didn't find any mention of such behavior.
The documentation say that +k "expands PCS keywords," but I can't find an explanation of where it's used. In the submit command? In the filemap?
If the former, I apparently must use p4 instead of p4v to utilize this feature, which our work processes would make very difficult. (I searched the P4V documentation for "RCS" but found no references. I searched it for "Microsoft Word" but found no relevant ones.)
If the latter, unless the filemap just happens to already be set up correctly, I'll have to enlist the server administrator to change it for me, which is about as likely as changing a law of physics.
One doc page says that I can list the filetype of open files (among other information) by running the command p4 opened. I tried that and got the message "Unknown command. Try p4 help for info." p4 help commands lists p4 opened as a valid command, but since p4 doesn't recognize it, I wonder whether the administrator has disabled this feature.
Posted 01 June 2020 - 06:10 PM
The way to do this at the command line is just p4 edit -t +k (file) followed by p4 submit.
In the interest of not requiring any laws of physics to be bent unnecessarily, here it is in P4V:
As I said, it works in Word files (the last time I tested it) by virtue of the fact that Word files contain ASCII. The keyword expansion logic is simply scanning the file for specific ASCII patterns; it doesn't care about what the rest of the file looks like, even if it's binary gobbledegook.
If modern Word files are compressed by default (as implied by the ubinary type thing you mentioned), it won't work so well, but I'd bet there are options when saving the file that might make it something more friendly (I could swear someone told me that current versions of Word will just save docs as XML instead of in a weird proprietary format). It's been many years since I had a licensed copy of Word so I can't do the experimentation myself.
A server admin can't "disable" commands that way. Okay, they could technically stick a proxy between you and the server and have it give you a fake error message in response to specific commands, but Occam's Razor suggests that you just typo'd the word opened.
Posted 20 July 2020 - 06:01 PM
Unfortunately it didn't work. I added $Revision$ to a document's header, checked the "+k" box in the Change Filetype dialog, and checked the file in. When I reopened it, the heading just said $Revision$. I thought that force-loading the current reversion might correct the problem; it didn't.
Do you think I might have to say $Revision:$ (with a colon)? If so I can try that the next time I revise a file... or the next time i remember!
Posted 20 July 2020 - 06:45 PM
If it does, you could try different format/encoding options when saving the file to see if any of the available options will save the file in something close enough to ASCII that it doesn't mangle unformatted strings.
Posted 21 July 2020 - 11:46 AM
I assumed that Perforce understood this and knew how to get at a .docx file's content because Word is such an important tool in its user community, but... maybe not. If not, that's the problem, and there's probably no solution except returning to using the old .doc file format, which is impractical for both technical and political reasons.
Posted 21 July 2020 - 02:45 PM
The easiest solution at that point is probably to manually update a counter in the file. That's potentially a thing you could automate to some extent by writing some kind of trigger in Perforce (e.g. a content trigger that validates that the counter is different from the last revision and reminds you to update it if it hasn't).
A useful enhancement request for Perforce that would make this work without having to special-case Word files specifically might be to apply keyword expansion to ubinary+k files after attempting to unzip the file (on the assumption that ubinary files are usually typed that way because they were zipped on the client), rezipping them after expansion if successful. You'd need to have an active support contract to be able to make a request like that though.
Posted 24 July 2020 - 12:15 PM
And this is not a situation where Perforce could add a feature that just unzips the file, makes the change, and zips it again. In my test case the ZIP contains 29 files in 5 directories. Perforce would have to know which one to change. In a docx file I suspect (but am not sure) that it could harmlessly search every file and change every keyword it found, but even if it is so, it would not necessarily be so for other filetypes, making the feature unsafe to use.
I just thought of a workaround: I could write a Word macro that runs automatically when a file is saved, and updates a timestamp only if it is running on my computer. The revision that the other user based their work on would be the first one with a timestamp later than the one the macro created. My VBA skills have been rusting for a couple of decades, though, so it wouldn't be easy.
Also tagged with one or more of these keywords: Microsoft Word, Timestamp, Revision number
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users