API to get past file version does not have correct timestamp

dking513 · Post by **dking513** » Tue Mar 07, 2006 7:53 am

Hello,

To get a specific older version of a file with the API I am doing the following:
-----------------------------------------------------------------
svFile = g_svCI.TreeCache.Repository.Root.FindFileRecursive(FullPath)
svFileClone = svFile.Clone(svFile.Parent)
svFileClone.Version = OlderVersionNumber
svFileClone.ObjVerID = GetObjVersionID(svFile, OlderVersionNumber)
g_svCI.Get(svFileClone, False, VaultClientOperationsLib.MakeWritableType.MakeAllFilesWritable, VaultClientOperationsLib.SetFileTimeType.CheckIn, VaultClientOperationsLib.MergeType.Unspecified, OP)
-----------------------------------------------------------------

Notice that when I do the Get, I specify the file timestamp as SetFileTimeType.CheckIn.

The problem is that the TXDate of my svFile object is that of the latest checkin, and this is the timestamp I get, even though I get an older version of the file.

The only way I have figured out around this is to do a history query on the file, and lookup the checkin date for the version number I am interested in, and then set the transaction date for my svFileClone object.

Is there a better or more efficient way to do this?

Thank you.

dan · Post by **dan** » Tue Mar 07, 2006 10:13 am

Take a look at the GETVERSION command in the command line client source. You should probably be using the GetByDisplayVersion() function. If the command line client sets the date the way you want, then the code there is the example to follow.

dking513 · Post by **dking513** » Tue Mar 07, 2006 11:19 am

I'm using the Get method instead of GetByDisplay version because I want to make use of the cache, so the command line client code won't work for me.

My way works as long as I make the history query to get the check-in date.

Is there any faster way to lookup a check-in date for a specific version of a file?

dan · Post by **dan** » Tue Mar 07, 2006 11:34 am

I can't think of a faster way to do it. Get() wasn't really designed to get a historical version, and probably assumes the file date is the latest checkin.

I'm pretty sure that GetByDisplayVersion uses the cache. If it doesn't, it should. The GetToNonWorkingFolder functions are the ones that don't use the cache. Were you running into performance problems using GetByDisplayVersion?

dking513 · Post by **dking513** » Tue Mar 07, 2006 11:45 am

I would prefer to use GetByDisplayVersion, and I tried this originally, but it didn't use the cache. Check out the support thread I created back then:

http://support.sourcegear.com/viewtopic.php?t=4675

dan · Post by **dan** » Tue Mar 07, 2006 11:59 am

Ah - I see. I guess I am wrong. I'm glad to get that out of the way for the next hour or so

It looks like at some point you are saving off historical versions of the file (by ObjVerID). Is the date always available then? That way you wouldn't have to hit the server again just to get the tx date.

Another idea, although probably a dead end: Is your default user option for SetTime set to checkin date or current date? If you set it to checkin date, does that affect the Get() call?

dking513 · Post by **dking513** » Tue Mar 07, 2006 12:14 pm

I have to query for the ObjVerID as well, so it's not like I have the date left over from a just prior action. But, maybe I can combine getting the Date and ObjVersionID which will help a bit.

As for your point #2, I'll have to look into it.
I have noticed that whenever a file is placed in the cache, it has the current date, not the check-in date, maybe this is related.