SourceGear Support

I've been writing to the client API and have created a report that scans through all repositories and gets a VaultClientCheckOutList. I am scanning through each of the items in the list and getting the user, path, and lockedwhen properties for reporting. The problem is that the lockedwhen property does not change when I expect it to.

If for example, I check out a file and lock it exclusively, make modifications, and then check it in with the "keep checked out" checkbox checked, the lockedwhen property does not change as expected. I also discovered that I'm sometimes appearing multiple times in the VaultCheckOutItem.Users[] array but it appears that the last entry is always the latest (correct me if I'm wrong). The LockedWhen property does change as expected if I check in the file without keeping it checked out, and THEN check it back out after the check in has already been transacted in a previous step.

Our users are used to using the "keep checked out" feature, and we don't want to force them to discontinue the use of that feature simply so we can get accurate metrics of how many files are checked out, by whom, and when they locked it last.

Is there a way to find out when the last checkout was for a specific repository/user/file was when the file is currently checked out based on the VaultClientCheckOutList or should I be going down some other path entirely to get that information?

thanks,

JE

I've been thinking about this, and I might have a workaround for you. If you have a lockwhen datetime, compare it to the TxDate on the file in the tree (use FindFileRecursive to get the file object). If TxDate > lockwhen, then use TxDate as the date that the checkout was "renewed". This is only 100% accurate if the files are exclusively checked out, but it's a possibility.

jeremy_sg wrote:If you have a lockwhen datetime, compare it to the TxDate on the file in the tree (use FindFileRecursive to get the file object). If TxDate > lockwhen, then use TxDate as the date that the checkout was "renewed". This is only 100% accurate if the files are exclusively checked out, but it's a possibility.

Jeremy, thanks for the reply.

Is there another way to get the file checked out date/time for the user when it's locked? At this point I have both the full path to the file and the user's name at this point already.

I've figured out how to get to the VaulClientRepository, then the VaultClientFolder and THEN the VaultClientFile. I'm assuming the TxDate is the date that the file was last checked in? I think for now this will get me what I need, but it would be nice if I could perform a similar operation on a per user basis should shared checkins (cvs style) were being used on a project/repository.

thanks,

JE

jerwin wrote:If for example, I check out a file and lock it exclusively, make modifications, and then check it in with the "keep checked out" checkbox checked, the lockedwhen property does not change as expected.

Jim:

This is by design. When a client commits a change set, the server usually removes the lock on the file. However, when a client asks a Vault server to keep the file checked out, the server skips the undo process thus preserving the original checkout lock (this keeping the file checked out). With the original lock in place, the lockwhen date will not change.

HTH

jerwin wrote:Is there a way to find out when the last checkout was for a specific repository/user/file was when the file is currently checked out based on the VaultClientCheckOutList or should I be going down some other path entirely to get that information?

If you need this metric, you're going to have to use history along with the checkout date.

You would need to do a NOW() - the MAX of the last checkout date OR the greatest version in history for this given user on the given file. Use the history query filter to get the history for a given user for modifications only returning only one row in date descending order.

Jeff and Jeremy,

Thanks for your prompt replies. For now, since we are using exclusive locks exclusively <g>, the TxDate comparison with the LockWhen will do the trick. Once we start going down a path of shared checkouts, I'll have to revisit how I'm getting the information. I'll probably re-open this thread at that point.

regards,

JE

No problem. Let us know when you need any help.

Cheers.