Help hooking DIFF -- Full Vault path of a version

[StevenBlack]

(Reposting this here because it's not getting any traction in the sleepy DiffMerge section -- It's not really DiffMerge, it's how Vault invokes Diffmerge)

We've got a pretty big repository with several branched trees.

So far we've had good luck hooking the DIFF process using a wrapper program, but we've got one snag that looks intractable.

In our situation, we sometimes need to bring-down a second file (a companion structure), generate the source, and DIFF the result.

We're using the Vault Command Line to GET or GETVERSION files from Vault. So far it's all cool (if unconventional) except for the following problem:

PROBLEM: Not enough information is being passed in the %LEFT_LABEL%, %RIGHT_LABEL%, %LEFT_PATH%, and %RIGHT_PATH% tokens in some circumstances.

Example: Say I want to DIFF file Foo Version 5 in Project A with an arbitrary Working Version of Foo somewhere on disk. Our DIFF wrapper handles this EXCEPT the %LEFT_LABEL% of foo just says:

Code: Select all

%LEFT_LABEL%= "File: Foo Version: 5"    <-- No Vault path  

BUT when comparing the latest Repository Version of Foo, the label will say:

Code: Select all

%LEFT_LABEL%= "Repository version ($/MyProject/MyFolder/Foo)"  <-- Note the Vault path 

The Vault path of Foo ($/MyProject/MyFolder/Foo) is critical in fetching Foo's companion structure by our DIFF wrapper. Moreover different incarnations of Foo exist in various other trees so it's not like we can just parse the XML from a recursive LISTFOLDER call because Foo isn't singular. Foo can live in several projects.

QUESTION, therefore:
1) Are there other DIFF tokens we can use besides %LEFT_LABEL%, %LEFT_PATH%, %RIGHT_LABEL%, and %RIGHT_PATH% ?? Specifically looking for a token that tells us "$/MyProject/MyFolder/Foo" for an older (historical) version of Foo.

See, behind the scenes, our DIFF wrapper calls GETVERSION again if the file being fetched has a companion structure. For historical versions, %LEFT_LABEL% and %RIGHT_LABEL% don't tell us enough to infer where that may be.

I'm considering a back-door kluge involving back-mapping the working folder to a Vault path, but gawd, there has to be a better way. I mean, c'mon

Thanks for any input you may have on this.

[jeremy_sg]

Yes, you've seen correctly. Any time a diff involves a historical version, we don't show the path. There is a real reason why, and it gets pretty deep into how Vault works.

An item in the history query results window does not know of its path at the time of the operation that committed that version. The path at the time of the operation is not necessarily the current path. What's even more complicated is that (in the case of a shared file) the commit happens to all paths to the item at once. So the only bits of data that the history window's items contain is the file's name at the time and its version.

So in response, there's not any variable that you can pass that will print out the path you want. If you want to email me using the button beside this post, I may be able to talk through your needs and help you to code an API program to help you, but I don't think that going through the Diff command line arguments will ever do what you want.

[StevenBlack]

I sent an email to you yesterday evening, as you suggested, but have not received a reply from you as of yet.

Considering that, to get my Diff process started, I right-click on an item in a tree in the Vault UI, it ought to be pretty simple to surface this. In this sense, it really doesn't matter a whit how Vault works internally. I right-clicked on an object that has a clear and determinate hierarchy as displayed in the Vault UI. How Vault works internally is therefore irrelevant to this particular problem since I'm interested in the very obvious and determinate hierarchy that was displayed to me when I right-clicked on it.

I'd expect that, in a more perfect world, the Vault right-click and ESPECIALLY the DIFF process, would be more open to extensibility than it evidently is (isn't).

What's really a bummer is Vault apparently only provides the %LEFT_LABEL%, %LEFT_PATH%, %RIGHT_LABEL%, and %RIGHT_PATH%, and these often contain arbitrary and demonstrably flaky values (including CR and LF characters), and there are no other %tokens% available, which is somewhat unbelievable considering that this is supposed to be a major extensibility point.

[jeremy_sg]

For anyone else reading this thread, I spoke with Stephen offline, and he has a workaround in place that will help him track down the companion files with only the file name. He's going to mail me examples of CRLF characters in the parameters, so that I can get that fixed as well.