SourceGear Support

GregM wrote:I can confirm this behavior, and I've complained about it before. You can Get a specific version from the history dialog without setting a working folder, but not the latest version from the main window.

That's still bringing up the Set Working Folder dialog for me.

Ok, thanks. It doesn't seem to be a huge problem or anything, since like you said, we can just tab to whatever we need. I just figured I'd check on it, since a couple folks brought it up to me.

I have the option set to show the Get Latest Version dialog. The problem is that the Set Working Folder dialog shows up before the Get Latest dialog if no working folder has been set. There are several instances where we'd want to Get Latest on several different repository folders to the same local ...

Not unless a working folder is already set. What I mean is, if I go into Vault and try to get latest on a file for which there is no working folder association, it will make me set a working folder before it will let me get that file. Once I've set that working folder, then sure, I can get the file ...

Ok then, let me ask you this: is there a way I can Get Latest Version without setting a working folder association? That would work for me, too.

Since our upgrade to Vault version 3.5, we've been getting the error: "The following repository path is already assigned to this working folder:" when we try to set a working folder assignment. Seems this version of Vault won't let us assign the same working folder to more than one Vault f...

Has this ever been resolved, or is there any kind of workaround? I have several users who are starting to complain about this issue now that we're beginning to migrate over to Windows 2003 Server for our workstations.

Actually, go ahead and forget about it. I got it figured out.

How do I go about getting the local checkout path of a checked-out file? I can see that the Vault client can find the checkout location even when the working folder assignment has been lost. Is there a way I can do that with the Vault API? I try the client.TreeCache.PhysicalPath, but that requires a...

I found the cause of my problem here. When I'm setting the properties of the Vault client object, I'm setting: client.WorkingFolderOptions.StoreDataInWorkingFolders = False; The user who consistently gets the error I mentioned above has their Vault "Store Working Folder State/Baseline Files&quo...

I'm not sure if I'm following you here. But then, I'm not sure I have the slightest idea of how labelling works, so that's probably why.

We have files that we end up branching to different locations, but seldom actually edit. So we don't really need to maintain a history on these files since they never change, and we'd rather not get a new date stamp on these files when we branch them, which Vault does. So at the moment, we're gettin...

Well, copy the file without branching it. Basically the same as getting latest on the file, then adding that same file to a different Vault folder. That's what we've been doing to "copy" files.

That's cool. I don't suppose you've happened to find a "Copy" command hiding somewhere?

We've had a lot of users here who've been using branching as a way to move files from one folder to another. You know, branch the file to the target location, then delete the file from the original location. This has resulted in us having a large number of deleted files which can apparently never be...