SourceGear Support

Just to be clear, after clearing the cache and setting the baseline count to 1, should we expect the cache folder and the source folder to pretty much remain in sync (size wise)?

+1 on the vote count here. Many developers here have complained that their Vault cache is well over 100GB , which is more than 3 times the size of the corresponding source directory. And when you're working with solid-state drives (where space is far more precious), 100GB can be a very large percent...

I would agree that, for this type of workflow, the new way of auto-selecting check boxes is no good at all. I'm really not sure why they've decided to go with this "auto-check on selection" method, especially when selecting any place other than the checkbox column results in all other chec...

I'm mainly just happy that "Commit selected" is back on the context menu. It might be worth noting that if you click just over the checkbox column , your previous selection remains checked, therefore allowing independent selection of rows. You can also append to your current selection by h...

Just to let you know, the change looks perfect! I like having the option to use check-boxes for selection but always having right-mouse context support for Commit.

Thanks for fixing this!

Much appreciated.

Is it possible to use this newest Vault client with 5.1.1.19215 Vault server? I ask because I'm interested in just seeing this change on my machine prior to "officially" upgrading to the latest version.

Please inform.

Thanks,

--Dave Novak

Will this fix still be rolled in to the 5.1 release as promised earlier?

Just to place to the expectation appropriately, I would intuitively think that Abort should be virtually instant, taking < 15 seconds (tops) to complete. My experience shows that sometimes Abort returns in a reasonable time-frame, yet the more typical case I've seen (depending upon when I click the ...

Does Vault support the concept of aborting (or canceling) a Get Latest operation? I see that the Abort button is enabled on the toolbar and I can click this during a long Get operation, but it doesn't seem to work. Instead of immediately canceling the Get operation, the Get operation continues on it...

Thanks for the update. I suspect that our usage of Vault is quite typical, yet we've managed to populate this one repository with over 28,000 folders in just 1 1/2 years. And with that many folders, I can see why a non-optimized query would return very slow results for a recursive search. Changing V...

Problem Solved It turns out that 100% of the slowness is due to Show Labels... defaulting to recursive search. A colleague here found the Act on queries recursively checkbox option (under Options --> History/Labels) and un-checking that yields nearly instant label results. Personally, I think that ...

No, we do not have a lot of labels applied to folders under $/. We have a total of 12 labels applied to $/, we have 4 folders directly off of $/, and only one folder contains additional labels (other than those inherited from $/). And the one with additional labels has only 4 additional labels and 2...

Yes of course these labels were applied directly on root $/, which is why I am asking Vault for those labels. As to folders/nodes in the tree, I really have no idea short of a manually counting (and Vault itself doesn't apparently answer this question either from what I've seen). Is there, perhaps, ...

So slow, in fact, that we've seen timeouts on the database. When we get errors, here's an example of what the error looks like in the log file: ----3/28/2011 2:10:28 PM dnovak--dnovak-uberpc.xaviant.net(192.168.200.102)--SSL Disabled System.Data.SqlClient.SqlException: Timeout expired. The timeout p...

Good! I'd really appreciate it if this was released as part of 5.1.x. Thanks.