Command Line - GETVERSION to working folder?

montek · Post by **montek** » Mon Mar 22, 2004 11:44 am

Is there a way to use the command-line GETVERSION to get a specific version to the working folder? It seems to force me to either use GET (which gets the latest version; not desirable) or GETVERSION with a specified destination path. The problem is two-fold: (a) I don't want to have to specify the destination path because it should already know and (b) I want my local client to also KNOW about the version extraction.

If I use GETVERSION specifying a destination path, the client always sees the file as renegade.

Also, is there a way to use the command-line client to query which version of a particular file I already have?

Thanks in advance.

Post by **jclausius** » Mon Mar 22, 2004 2:10 pm

monte:

in vault 2.0.x, getversion acts as a get to non-working folder.

i haven't found a way to get a historical version to a working folder. i've added a feature request to allow getversion to work on a working folder.

montek · Post by **montek** » Mon Mar 22, 2004 2:24 pm

Thanks, as always, Jeff.

Post by **jclausius** » Tue Mar 23, 2004 8:38 am

monte:

as a follow up, i've logged a customer feature request to to enhance getversion to work on working folders.

montek · Post by **montek** » Tue Mar 23, 2004 11:13 am

Excellent. Thank you. Any thoughts on my second question:

Also, is there a way to use the command-line client to query which version of a particular file I already have?

Post by **jclausius** » Tue Mar 23, 2004 11:23 am

Also, is there a way to use the command-line client to query which version of a particular file I already have?

Sorry, no. I've added this as a request as well.

Keep those features coming.

Post by **jclausius** » Tue Mar 23, 2004 11:34 am

in the meantime, two (ugly) possible work-arounds

1) use LISTFOLDER to list the contents of the folder. parse out the file in question

2) use HISTORY and use/parse the last item. Note a third feature request - user can specify sort on history (at least ascending / descending on version)

montek · Post by **montek** » Tue Mar 23, 2004 11:41 am

Thanks for the tips! If I write my own program and use the API directly, I presume I could do both things I want to do, yah?

Post by **jclausius** » Tue Mar 23, 2004 11:52 am

yes!

1) grab the client api ( http://www.sourcegear.com/vault/downloa ... _2_0_1.msi )

2) sample from jeremy ( http://support.sourcegear.com/viewtopic.php?t=450 )

3) look at using vaultcmdlineclient.cs. it is the source code for vault 2.0.1 command line client.

montek · Post by **montek** » Tue Mar 23, 2004 12:12 pm

Excellent! I was hoping to not roll up my sleeves, but I'm really glad I have that option! =)

montek · Post by **montek** » Wed Mar 31, 2004 7:37 pm

So, I'm uh having a few problems. =) Are there any useful examples of what to do in the API to accomplish this:

Given a path to a file in the repository, I want to use the API to determine which version I have locally on disk.

I've been attempting to use this, which *does* seem to be working, but I don't want to screw anything up (the TreeCache business makes me nervous). "path" below is like "$/project1/fun.aspx" or something.

Code: Select all

VaultClientFile file = client.TreeCache.Repository.Root.FindFileRecursive(path);

if (file == null)
	throw new Exception(string.Format("{0} does not exist", path));

WorkingFolder working = client.GetWorkingFolder(file);
return (working.GetDisplayVersion(file));

So, it seems to work, but the intellisense warning about using .FindFileRecursive made me nervous (it suggests not to use this). Am I on the right track? =)

I notice already that it returns the last version retrieved from the Vault, without regard to renegade changes which I shall endeavor to have it tell me.

sterwill · Post by **sterwill** » Wed Mar 31, 2004 9:00 pm

The warning for FindFileRecursive should only apply to the version that takes an integer ID. Because a shared file has the same ID, but is found in multiple locations in the tree, that version of FindFileRecursive will only return the first one it finds, even though there may be more. The version that takes a full path string can only return one file (null if not found), so it's safe to use.

All items in the TreeCache structure represent the server's latest repository structure. A file you find here may not necessarily be the latest version you retrieved, it's just the latest version available on the server. You'll need to create a WorkingFolder object and query it for the baseline version of a file to see what the actual version you have on disk is.

montek · Post by **montek** » Mon Apr 12, 2004 5:18 pm

I'm moving along... Now my question has to do with removing an existing label. I think I can do the adding a label (though slighly convoluted because the only exposed method expects objVerID instead of the display version, but I'll work with that). What's not clear to me is how to effectively use DeleteLabel, which is expecting a labelID. I'm not entirely sure how to retrieve that.

I know exactly which file (full path) and which version (though display version again, but I can translate) and which label (text) that I want to remove (assuming it exists; I'll code around any failures). Any suggestions?

montek · Post by **montek** » Mon Apr 12, 2004 5:36 pm

Hrmm...on second thought, I'm not sure it's as straight forward as I thought to get the correct ObjVerID.

montek · Post by **montek** » Mon Apr 12, 2004 6:13 pm

montek wrote:Hrmm...on second thought, I'm not sure it's as straight forward as I thought to get the correct ObjVerID.

'sokay, I'll answer my own questions (hehe) I've figured this part out. =)