SourceGear Support

Something unexpected is definitely happening. Could you try looking at the timestamp on the files between the get operations? Also, could you try checking the Use CRC option in the GUI client and Eclipse?

The main reason that we've never supported multiple repository connections or multiple server connections is that it doesn't work with atomic commits. In Vault we strive to make sure that when a commit succeeds, it works for all files that are checked in. I'm sure that you can appreciate the need fo...

There really isn't any way of connecting to multiple repositories. I'm sorry to disappoint you, but there aren't any plans at the moment to add that capability. All of our Vault clients have this particular limitation.

Is this a common occurrence for you? I understand that our tool failed you in this case. If you want to avoid this pain in the future, use the option to store cache information in the working folder. With that option you can move the working folder and cache together. Warning: when you set that opti...

It's not that easy in Vault. Are you on Windows? If so, bring up the GUI client. unset the working folder for Branch A, then set the working folder for Branch B to that location. Do a get on Branch B, choosing to Overwrite any modified files. You might also want to consider deleting the local conten...

Branches are designed to hold all items that get branched, not just the items that will change. The benefit of structuring this way is that a get of the branch will get all files needed for that branch to be built. The normal way of achieving the desired workflow: 1. Code in trunk up to the release ...

I think that you have a pretty complex problem. Please email support at sourcegear.com ATTN: jeremy with a link to this thread. I'll phone you to discuss your needs.

The ClientInstance should handle that event for you. I recommend that you do not add a listener for ResolveUnknownFilesEvent. The reason that this event occurs is that a file exists in the working folder, but was not fetched from Vault. The common cases for this: 1. The client cache directory was de...

What you're seeing is a limitation of our VSS import. The import must do the transactions out of order, since VSS has no concept of a "folder version". The history from VSS will always be out of order when viewed in Vault, but every checkin will have the correct date. Future commits in Vau...

You need to query the history using the ProcessCommandHistory() method in ServerOperations. Set the recursive parameter to false to specify that you only want changes to that folder, and not items below it. If you read the command line client source, which is included in the VaultClientAPI zip file,...

It seems like you don't have the reference to VaultClientIntegrationLib right in your project (or your using statement is missing). Does that seem possible?

Another option is to use the Vault Command Line Client to generate an XML file with the history, and then load and parse the XML file.

Before you spend time coding this, you should know that the Vault Show Labels dialog can delete multiple labels at once. The method would then be: Log in to the repo. Show labels on Root. Select a bunch. Right-click and choose delete. I'm unsure if that's in 3.1, but I know that it's in 5.0. You may...

You can also use the GUI client's Show Labels dialog to quickly delete multiple labels.

In the ClientAPI zip, the VaultClientIntegrationLib has a method called ServerOperations.ProcessCommandDeleteLabel(), which you could use to delete old labels.

SubscribeWatcher is for subscribing a user to emails when a folder changes.

What are you trying to do?