Feature Request: sgvault_

[JackTripper]

Why not only cache in the sgvault_ the files that i have currently checked out? If it's not checked out anymore, why is the file still in the vault? When is the GUI going to delete it?

Isn't it inherently wrong to have a file that is years, and will probably never be used again, lingering around?

i'd like to see an option in the IDE that says "Purge sgvault_ every xx days", or "Purge sgvault_ every xx seconds", or "Never use sgvault_"

i really don't mind the performance penalty of transferring a 50k file over the network. And since you can store hashes of files instead of the whole file, seeing if files have changed would not require a full download of all the files from the server.

i guess i don't get the design rationale of this.

My Develop directory is 1GB, my %AppData% drive has 500MB free.

And i'm the guy who would have to tell everyone,

"Okay guys, we're using a new SourceSafe. But every couple of days you'll have to go into your 'c, documents and setting, application data, local settings, application data, source gear vault, then a guid, i think, then your name' and erase everything in there."

"Why?", they'll respond.

"Because this program like to keep a copy of every file you've every touched in there. It speeds it up slightly."

"Ummm, okay."


It's just nasty.

[GregM]

If it's really that big a deal, create a scheduled task in Windows to delete the directory on a regular basis.

We work with 50 MB source trees. I'd hate to have to download that tree over the internet every few days.

[JackTripper]

There's no need to download the source tree again.

If the software wants to compare a project and a folder, it should download hashes of the files in the project. There's no need to download the entire source file just to see if two files are different.

If i then want to do an actual diff on files that are different, i will then download the file.


i've been testing SGVault against the open one run on SourceGear for a few days. The more i use it, the more frustrated i am with it.

i diffed a folder, a file was created in my local, and another needs to be deleted from the project. i try to right-click on the files per "Add Files" and "Delete Files" but i can't.

Then i need to perform a "Find in files" search. But that command, while exists in source safe, is absent from Vault.

Arrrgh.

i am pretty annoyed with how slow VSS is, but i guess i can wait a few more months for VSS 2k5.

Also, because i doubt SourceGear with make major paradigm shifts in Vault based on this one potential customers opinions...

[GregM]

If i then want to do an actual diff on files that are different, i will then download the file.

You already downloaded the file once, why would you want to download it again? As I see it, one of the major assumptions in Vault is that your hard drive is faster than the network, and reading a file out of the local cache is a heck of a lot faster than retrieving it over the network, especially if the internet at large is involved. If you're really really low on disk space, then I can see wanting to clean off the local cache.

I have to wonder, with 60 GB drives selling for under $100 these days, isn't disk space cheaper than your time?

i diffed a folder, a file was created in my local, and another needs to be deleted from the project. i try to right-click on the files per "Add Files" and "Delete Files" but i can't.

I'm pretty sure that's on their list of enhancements, adding source control hooks into their diff/merge program. On the other hand, with the way they've structured it now, to start, you're free to use your own favorite diff/merge program, and you can use their diff/merge program outside of Vault.

Then i need to perform a "Find in files" search. But that command, while exists in source safe, is absent from Vault.

Also on their list of enhancements.

i am pretty annoyed with how slow VSS is, but i guess i can wait a few more months for VSS 2k5.

I wouldn't hold your breath. There are reportedly only very minor changes in VSS for 2005, with no architecture changes. If you're referring to the new SQL-based product, prepare to pay a hefty premium for that. It's also version 1.0 of a new product, I'm sure it's going to have its issues as well.

Also, because i doubt SourceGear with make major paradigm shifts in Vault based on this one potential customers opinions...

I don't know how major they need to be, but they've been very responsive so far. They only released 2.0 a few months ago, and they've already had 3 point releases, and said that another point release is coming soon, with a minor release soon to follow.

The automatic purging of the cache that you're looking for can be done quite easily in Windows. You then have to download more files more often, but you seem to be okay with that.

[JackTripper]

You already downloaded the file once, why would you want to download it again?

So i can diff with what's in the vault.

As I see it, one of the major assumptions in Vault is that your hard drive is faster than the network, and reading a file out of the local cache is a heck of a lot faster than retrieving it over the network, especially if the internet at large is involved.

The normal operation is to see IF my local copy is different than either :
a) the vault, or
b) what i last checked out.

Either way, i don't need another whole copy of every file. i would only need the hash.

Now that's to see IF a change has happened.

Next, we talk about actually SEEING the differences between my working copy and either:
a) the vault, or
b) what i last checked out.

For the former, the local cached copy of the file does me no good, because it may be different than what's in the vault.

For the latter, yes, technically a local cached copy is faster. Unfortunatly, i NEVER want to use that case. When i compare my local file to the vault, i want to compare it to the vault. That means that i have to download the file anyway.

So now we have 4 types of operations to perform, and in only 1 is a cached copy relavent.

Also, i've been testing Vault over the internet. It's not that much slower than SourceSafe over a LAN. Yes, it is slow right now when i have to diff a folder, but that's because SourceGear doesn't download hashes of files, but the actual files.

As it stands, the way i (and anyone who expects the software to act like a compelling replacement for SourceSafe) have no use for the locally cached copies of files.

But now you might wonder how the UI can watch your files, and show you which ones have been modified. There are more optimizations to be had. They can store the size and hash of the file when you checked it out. Now you can see that a file has changed (so the UI can show you "Modified", "Unchanged", -1 bytes, etc).

But now let's say that you REALL REALLY LOVE performing a contents diff against the version of the file that you checked out. And you have decided that you just CAN'T wait for the file to download over the LAN (which is the most common case) or the Internet (which isn't that slow in my experience with Vault so far); then there will have to be a local copy.

But why, in the name of everything bleepable, do you need that cached copy after you have checked in the file?

If you're really really low on disk space, then I can see wanting to clean off the local cache.

The point is not that i may be low on disk space (although i am, on my %AppPath% drive), it's that it's wasteful. There are so many other optimziations that can be had. It's a brute-force, ugly, wasteful idea.

And as i detailed above, the way my company and i use SourceControl, it is absoutely unneeded; and therefore completely wasteful.

I'm pretty sure that's on their list of enhancements, adding source control hooks into their diff/merge program. On the other hand, with the way they've structured it now, to start, you're free to use your own favorite diff/merge program, and you can use their diff/merge program outside of Vault.

Yes, and i love the diff program BeyondCompare, and i understand that if i use BC i won't be able to "CheckIn", "CheckOut", "Add", "Delete". But the fact that's it's not there now is almost a show-stopper. But i trust that the feature is coming.

Then i need to perform a "Find in files" search. But that command, while exists in source safe, is absent from Vault.

Also on their list of enhancements.

It was last Thursday that i finally said to myself that i've had enough of VSS. i remembered a link on the SourceSafe homepage to SourceGear's SourceOffSite product. And i remember their "compelling replacement for SourceSafe". i thought it was compelling because it was a clone of VSS (even if some CVS users think that VSS has some strange paradigms for version control). As such, i thought what's in VSS would be in SG.

I wouldn't hold your breath. There are reportedly only very minor changes in VSS for 2005, with no architecture changes. If you're referring to the new SQL-based product, prepare to pay a hefty premium for that. It's also version 1.0 of a new product, I'm sure it's going to have its issues as well.

i was referring to the SQL product. i can't imagine that MS would release another VSS based on shared files. There are so many built-in limitations, bugs, crashes, data-loss associated with that; i assume they'll re-write it into a product fitting the Microsoft name (not something they bought from someone else)

i read that there is no "Sharing" of files. Which is definetly a show-stopper for us, but it was tempered with "for now." On the other hand, i'm not too concerned with price - worse comes to worse, and a quick trip to eMule will fix that.

I don't know how major they need to be, but they've been very responsive so far. They only released 2.0 a few months ago, and they've already had 3 point releases, and said that another point release is coming soon, with a minor release soon to follow.

The automatic purging of the cache that you're looking for can be done quite easily in Windows. You then have to download more files more often, but you seem to be okay with that.

Not automatic purging - not using at all. Use of hashes/checksums/CRC32's. They would need to go back and make the server calculate the hash every check-in, and the client has to get a hash on check-out. And the clients have to now calculate hashes on folder contents when performing a folder diff.

And if the user leaves on the option to have cached files on check-out, to delete them on check-in.

It's a lot of major structural changes, that would need to happen before i can get my hands on a copy of VSS2k5.


i guess i just had high hopes when i first saw the product, "Finally, SourceSafe done right." In another day or two, my VSS import should be done, and i'll tell everyone to look at it. But i'll point out all the bugs and frustrating quirks that it has; and tell them not to get too much into it - because VSS2k5 might be better.

But i'll let them give it a chance.

[jclausius]

Why not only cache in the sgvault_ the files that i have currently checked out? If it's not checked out anymore, why is the file still in the vault? When is the GUI going to delete it?

Jack:

The _sgvault directories exist for baselines that you have retrieved with a "GET". You have a point, that the files do not need to exist if the user uses Vault with the Checkout / Edit / Checkin option. However, there are a lot of people who use the Modify / Merge option (similar to CVS). This manner of working requires baselines to determine what needs to be merged. In the end, only one code path for the GET operation supports both options.

Isn't it inherently wrong to have a file that is years, and will probably never be used again, lingering around?

i'd like to see an option in the IDE that says "Purge sgvault_ every xx days", or "Purge sgvault_ every xx seconds", or "Never use sgvault_"

Other people have raised the same concerns. Customer feedback is important, as it drives some of the functionality into the product. We have logged a feature enhancement to do address this very problem.

My Develop directory is 1GB, my %AppData% drive has 500MB free.
...

Have you thought about setting the option to store the _sgvault folders in-line with your working folders? I actually prefer using this option of the Vault client. It makes disk management a little easier, not to mention working around moving projects on disk or renaming a path to a project.

[jclausius]

There's no need to download the source tree again.

If the software wants to compare a project and a folder, it should download hashes of the files in the project. There's no need to download the entire source file just to see if two files are different.

Jack:

I thought the same thing. In fact, this was exactly how Vault 1.0.x worked. However, people found the feature lacking. Customers wanted to diff against a different folder in the repository. Others wanted to diff against a folder not in the repository. Well, what about diffing against a label.

Then other requests came - I don't want to use the provided SG diff tool, but my own. I've invested in Beyond Compare... I want to use Araxis... What about allowing us to use those?

So, the only way the Vault client could solve these types of problems was to actually place the files locally.

Then i need to perform a "Find in files" search. But that command, while exists in source safe, is absent from Vault.

We've had numerous requests for this feature. I'll add your name to this list.

Also, because i doubt SourceGear with make major paradigm shifts in Vault based on this one potential customers opinions...

Sounds like you've been stuck using a Dev Tool provider who doesn't listen to customer feedback.

Jack, thanks for providing us with this feedback. In your last two posts, you've listed concerns expressed by other people. We value everyone's input. People would be surprised if they knew how their feedback drives our feature sets.