Source Safe Versus Source Vault
Moderator: SourceGear
Source Safe Versus Source Vault
Hi All,
Any ideas / comments / experiences on Source Safe Versus Source Vault.
Thanks.
Any ideas / comments / experiences on Source Safe Versus Source Vault.
Thanks.
sean:
come on you vss importers, speak up. we'd love to hear from you.
sean, i feel better about providing my biased opinion here
these are off the top of my head.
1) reliable storage medium. just check the vss newsgroups and vss bloggers. most of them recommend running vss analyze once a week to fix any database corruptions. vault is stored in sql server. most maintenance i would recommend is to tune indices and table statistics which just make the application that much faster.
2) web services / .net - using web services, vault is ready out of the box for distributed (internet) connectivity.
3) atomic transactions. atomic transactions insure you don't end up w/ a "half-baked" source tree. imagine the dilemma when 5 of the 15 files you just checked in didn't make it. and wouldn't you know it, 5 minutes after you notice the 5 failures, another developer is sending out a message, "alright, who busted the source for the build?" with vault, either all 15 files are checked in or nothing.
4) true folder share. try this one out -> share a folder within vss. now add a file to the folder you just shared. notice this file does not appear in other shared location. now share a folder in vault. try the same thing. add a file to the shared folder. notice this file appears everywhere the folder is shared.
come on you vss importers, speak up. we'd love to hear from you.
sean, i feel better about providing my biased opinion here
these are off the top of my head.
1) reliable storage medium. just check the vss newsgroups and vss bloggers. most of them recommend running vss analyze once a week to fix any database corruptions. vault is stored in sql server. most maintenance i would recommend is to tune indices and table statistics which just make the application that much faster.
2) web services / .net - using web services, vault is ready out of the box for distributed (internet) connectivity.
3) atomic transactions. atomic transactions insure you don't end up w/ a "half-baked" source tree. imagine the dilemma when 5 of the 15 files you just checked in didn't make it. and wouldn't you know it, 5 minutes after you notice the 5 failures, another developer is sending out a message, "alright, who busted the source for the build?" with vault, either all 15 files are checked in or nothing.
4) true folder share. try this one out -> share a folder within vss. now add a file to the folder you just shared. notice this file does not appear in other shared location. now share a folder in vault. try the same thing. add a file to the shared folder. notice this file appears everywhere the folder is shared.
Jeff Clausius
SourceGear
SourceGear
We imported our Source Safe into Sourcevault and have been working GREAT ever since.
The 'Feature' that sold us the most was the ability for my project team to connect to Source Vault from the internet. This was impossible in Source Safe.
Second, I like the fact that I can backup my SQL Server database and feel confident about recovery if need be. The Source Safe directory structure and naming conventions always made us nervous.
The 'Feature' that sold us the most was the ability for my project team to connect to Source Vault from the internet. This was impossible in Source Safe.
Second, I like the fact that I can backup my SQL Server database and feel confident about recovery if need be. The Source Safe directory structure and naming conventions always made us nervous.
I know this is an old thread, but it may be worth while me adding my experience. Help to convert more suicidal VSS users
Our previous setup consisted of several VSS databases, serving a team of in house developers and 3 remote, via Source Off-Site.
We now have a 7 repositories in our SGV database, imported from VSS. Our largest repository is approx 10,000 files and around 8 months history. It would be a much larger history, but the old VSS database corrupted itself beyond repair and would not archive, or successfully import into SGV Not a reflection on SGV, just a mangled VSS database.
I took a copy of each VSS database, ran analyze/fix and imported into SGV. VSS and SGV import tool running on one server, SQL and IIS running on the other. I did all the imports over a weekend, so that network/server use was as low as possible. No problems, the 10,000 file repository took about 2 hours to import (15,000 revisions).
Since the upgrade, the remote users have reported a speed increase over SOS/VSS.. particularly when doing a full Get. All users like the new interface and the pending change set.
The temptation for old VSS users (at least ours) is to try and replicate exactly what they did in VSS.. but most of the time, the same end result can be achieved in SGV much more efficiently.
Our build engineer typically did a diff on the whole tree to see if any files had changed without proper notification (10 minutes). Now all he needs is a Status Search for Old files (less than a minute).
Transactions are great for reliability, but also make it very easy to see all the files that were checked in together... try that in VSS.
Our previous setup consisted of several VSS databases, serving a team of in house developers and 3 remote, via Source Off-Site.
We now have a 7 repositories in our SGV database, imported from VSS. Our largest repository is approx 10,000 files and around 8 months history. It would be a much larger history, but the old VSS database corrupted itself beyond repair and would not archive, or successfully import into SGV Not a reflection on SGV, just a mangled VSS database.
I took a copy of each VSS database, ran analyze/fix and imported into SGV. VSS and SGV import tool running on one server, SQL and IIS running on the other. I did all the imports over a weekend, so that network/server use was as low as possible. No problems, the 10,000 file repository took about 2 hours to import (15,000 revisions).
Since the upgrade, the remote users have reported a speed increase over SOS/VSS.. particularly when doing a full Get. All users like the new interface and the pending change set.
The temptation for old VSS users (at least ours) is to try and replicate exactly what they did in VSS.. but most of the time, the same end result can be achieved in SGV much more efficiently.
Our build engineer typically did a diff on the whole tree to see if any files had changed without proper notification (10 minutes). Now all he needs is a Status Search for Old files (less than a minute).
Transactions are great for reliability, but also make it very easy to see all the files that were checked in together... try that in VSS.
What about Buildit.exe
I am evaluating Vault and am suitably impressed with the simulations I've run on my trial copy so far. I am trying to cover all my bases before recommending to my employer that we convert from VSS, and in particular I am currently looking to see whether Buildit.exe can be used with Vault? The Buildit.exe.config file seems to have VSS specific tags and attributes and am hunting for info from anyone who has successfully used Buildit with a Vault repository.
Thanks
Thanks
What about Buildit.exe (2)
Well, it seems BuildIt.exe is hardwired for VSS use only at this stage (although support for other SCC tools is listed as a "future" enhancement). In the meantime, I'm interested to know what build tool Vault users use? To that end, what build tool do SourceGear developers use?
Here at SourceGear, we have a home grown build script that uses the Vault command line client to extract files from Vault.
Ryan Duffield (one of our customers) wrote an integration task with Cruise Control, which is available here: http://support.sourcegear.com/viewtopic.php?p=2860
There has also been some work by other customers on Nant integration, but I don't believe it is zipped up into a nice downloadable file.
Hope this helps,
Ryan Duffield (one of our customers) wrote an integration task with Cruise Control, which is available here: http://support.sourcegear.com/viewtopic.php?p=2860
There has also been some work by other customers on Nant integration, but I don't believe it is zipped up into a nice downloadable file.
Hope this helps,