Jump to content


A way to timestamp or revisionstamp a submission?

Microsoft Word Timestamp Revision number

  • Please log in to reply
8 replies to this topic

#1 Orthoducks

Orthoducks

    Member

  • Members
  • PipPip
  • 19 posts

Posted 30 May 2020 - 01:36 PM

Is there a way to automatically add a timestamp or revision number to a submitted Microsoft Word document file, so that if the file is copied from the depot and modified, it's possible to tell which revision it's based on?

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.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 30 May 2020 - 02:30 PM

If current versions of Word docs still work more or less like they did twenty years ago, you should be able to do this by submitting them with the +k filetype and adding RCS-style keywords (e.g. $Revision$ or $Id$) to the content.  Since text content is generally represented within the doc file as ASCII, the keyword expansion logic should be able to recognize it and do the expansion within the doc even if the base filetype is binary.

#3 Orthoducks

Orthoducks

    Member

  • Members
  • PipPip
  • 19 posts

Posted 01 June 2020 - 05:22 PM

Sambwise: I tried putting $Revision$ and $Revision:$ in a document file I submitted and neither one was recognized, so I evidently need to do something more to utilize this feature. But I tried to figure out what "submitting them with the +k filetype" means, and I ended up chasing my tail. I'm sorry, but to be understandable the whole feature needs to be explained more clearly than the Perforce documentation does.

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.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 01 June 2020 - 06:10 PM

Quote

t I tried to figure out what "submitting them with the +k filetype" means

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:

Posted Image


Posted Image

Posted Image

Quote

But this assumes that Perforce knows how to read and modify a Word document file. Does it?

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.  :)

Quote

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.

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.  :)

#5 Orthoducks

Orthoducks

    Member

  • Members
  • PipPip
  • 19 posts

Posted 20 July 2020 - 06:01 PM

Sorry it took me so long to respond to this. Remembering it when I had an opportunity to try it proved difficult.

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!

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 20 July 2020 - 06:45 PM

It shouldn't need the colon.  Try opening the file in a text editor; does the $Revision$ string appear intact, or does it have extra binary junk mixed into it?

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.

#7 Orthoducks

Orthoducks

    Member

  • Members
  • PipPip
  • 19 posts

Posted 21 July 2020 - 11:46 AM

I looked in a text editor. The whole string is intact. But I'm not sure you're aware that when Microsoft added the 'x' to Word's preferred filename extensions (in Office 2007), the entire file format changed. It's now a ZIP file in all but name. To inspect the headers I had to rename the file from .docx to .zip, extract the contents with a ZIP utility, and inspect a file named word\header1.xml. This is not hard, but I don't think many Word users understand it, so I think you'd probably have warned me if you knew.

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.

#8 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 21 July 2020 - 02:45 PM

If it's zipped, there's no way that text-based logic is going to work on it.  I assume there's no option in the settings to save it uncompressed?

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.

#9 Orthoducks

Orthoducks

    Member

  • Members
  • PipPip
  • 19 posts

Posted 24 July 2020 - 12:15 PM

Changing the rev number manually does not seem practical -- there's no way I'll remember to update it consistently. Unfortunately if I forget 5% of the time I'll never be sure whether I remembered or not, making the rev number useless.

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