Local cache size in Documents and Settings

[bpd]

Our developers are complaining that their C:\ drives are running short of disk space when performing GetLatest from the root of our Repository tree.

Our repository is around 1 GB in size, and the cache files and folders in the Documents and Settings\ApplicationData\SourceGear folder seems to closely rival that.

Is all that cache necessary? Should it be cleared down automatically? Is there a client/server setting to reduce the reliance on the cache?

Regards

[jclausius]

Have you suggested to enable the Client Side option -> Store working folder data inside working folders?

This will then store all the Vault baseline data in a folder named _sgvault located in each working folder, rather than use the user's %APPDATA% directory.

[bpd]

Thanks I will give that a try

[Guest]

Why will that reduce the size?

[jclausius]

Good point. It won't reduce the size by itself.

However changing the setting will allow users to delete all %APPDATA%\SourceGear\Vault_1\Client\{Repository GUID}\{User Login}\_sgvault directories in those folders.

Removing those base line meta-data folders along with storing them in-line with working folder data will keep Doc & Settings clean.

[jclausius]

I should also issue a word of warning.

Changing the location of your working folder meta-data will most likely set files in the working folders to "unknown" in status. Anyone changing this setting should make sure all of their work is committed to the repository. Otherwise, they will be retrieving modified files out of the _sgbak folders upon the next get.

See Understanding the Vault Client for more information.

To end on a positive note, we are investigating ways to alleviate this annoyance in Vault 2.1.

[CraigNicholson]

To end on a positive note, we are investigating ways to alleviate this annoyance in Vault 2.1.

When is Vault 2.1 expected to be released? Surely it would be beneficial to put these kinds of questions into the Discussion forum so that existing users might actually contribute and help in improving the next version. So far I've only seen requests for new features, but no discussion of solutions.

Just an idea... use it.. or don't.

[jclausius]

When is Vault 2.1 expected to be released?

The post is a little old, but Dan commented here http://support.sourcegear.com/viewtopic.php?t=1659#5906

Surely it would be beneficial to put these kinds of questions into the Discussion forum so that existing users might actually contribute and help in improving the next version. So far I've only seen requests for new features, but no discussion of solutions.

There isn't really an official Vault 2.1 thread on the forum. We've addressed these questions on a post by post basis, and I believe most questions / discussions related to Vault 2.1 have been identified as such.

For those who have not been following the forum, searching for "next release" or "2.1" within the last 3 months should give an indication of what can be expected.

[George Mills]

This setting caching information about the state of your repository that is in one directory (your working directory) being stored in another directory really sounds scary to me.

We constantly tell our developers, what is on your local disk drive means nothing. It's what's in repository that only matters. We ask to rebuild their tree from scratch at least once a week to be sure you don't drift off baseline. This is simply done by making sure everything is checked in and renaming your tree myproject.old and doing a new get into the original working folder. I don't want them to rely on any cache information held in another folder.

Now I understand you have the option to store this cache info in the working folder itself. But I don't want to worry about each developer setting it right. It would be nice if this were a central admin option that the admin could either default or override the behavior of clients. Or default all clients to store this in the working folder.

[jclausius]

This setting caching information about the state of your repository that is in one directory (your working directory) being stored in another directory really sounds scary to me.

Yes, that would be scarey. But, you can relax. The repository's state is always contained within the server. The only information stored locally is the baseline versions of any files retrieved to a working folder.

We constantly tell our developers, what is on your local disk drive means nothing. It's what's in repository that only matters. We ask to rebuild their tree from scratch at least once a week to be sure you don't drift off baseline. This is simply done by making sure everything is checked in and renaming your tree myproject.old and doing a new get into the original working folder. I don't want them to rely on any cache information held in another folder.

Baseline files retrieved from the server are read-only, have non-intuitive names, and stored in _sgvault hidden directories. To be honest, it shouldn't matter one way or another about empty baselines. However, if you want to force users to get from empty baselines, you should verify the "Use working folder for working folder data" is enabled for everyone.

Now I understand you have the option to store this cache info in the working folder itself. But I don't want to worry about each developer setting it right. It would be nice if this were a central admin option that the admin could either default or override the behavior of clients. Or default all clients to store this in the working folder.

We've had this request before. At this point in time, there is a "hacky" work-around using a SQL Query to change everyone's option. Let me know if this is something you'd like to explore.