Wvaluating Vault for a move from SourceSafe

THONA · Post by **THONA** » Sat Mar 19, 2005 12:07 pm

Yes, finally I had enough. And VSTS is a LONG time in the future.

So, for the meantime I am evaluating Vault fo a move from sourcesafe.GOt and downloaded 3.0.5 and now I am stuck with some guidelines. I am right now running an import of a backup of our sourcesafe repository (just to see how it goes - if it goes well, then - I will do a real move into vault over the weekend and put one minor project over to vault on production for a month, let's see how this works).

Anyhow, I am a little lost in "best practices".

* Is there anything the fulyl describes the necessary steps for backup/restore? Automated. Is it enough to just make sure the sql server database is restored?

* One or more repositories. Right now the whole thing is structure in that all customers have a top level project in sourcesafe (including us, for our own projects). Unter these individual projects live. One repository per customer? We often cross-link projects into solutions. This imho makes one repository per customer hard. The issue is that we have some projects that are "ongoing work" - mostly incorporations of open source libraries, or Win32 integration stuff. Having them as VS.NET propjects makes upgrades / additions easier. Like upgrading to a new version of Lucene.Net, or adding missing declarations to some pretty hugh Win32 native interop projects.

* Licensing. I see the licenses. There is one thing I do not like. With Sourcegear I had the idea that when we move we could make limited licenses available for our customers. Limited as in "no checkout, no changes". What for? Well, they could grab copies of their source cheaply. Right now (Sourcesafe) we did so by using a tool similar to SourceOffSite - two installations, one for our developers, one with 5 licenses that our customers connect to. Keeping licenses costs down is something critical on those - it is more a service. There is no offer for this and no plan for "read only" licenses in Vault, right? And no, shadow directories are not an option. They are more a pain - with them you can not grab all changes in a source-hierarchy fast. This would also allow customers to be able to get "up to the minute" versions of developments - something important for us. Please note that a "guest" account would not really suffice - we need named accounts, due to directory security.

* So far so good

ar ethere any plans to incorporate a backup/restore feature like sourcesafe has it for infividual "projects"? We found customers really liked it that at the end of their project we could ship them something they can import into sourcesafe and just see how things changed.

Post by **jclausius** » Sat Mar 19, 2005 9:22 pm

I've answered things inline.

THONA wrote:* Is there anything the fulyl describes the necessary steps for backup/restore? Automated. Is it enough to just make sure the sql server database is restored?

All data related to your source code / repositories is stored within the SQL Server database. Backing up the sgvault database should pretty much take care of things. If you have some special server settings, you may also want to backup vault.config and web.config within the Vault server's directory.

THONA wrote:* One or more repositories. Right now the whole thing is structure in that all customers have a top level project in sourcesafe (including us, for our own projects). Unter these individual projects live. One repository per customer? We often cross-link projects into solutions. This imho makes one repository per customer hard. The issue is that we have some projects that are "ongoing work" - mostly incorporations of open source libraries, or Win32 integration stuff. Having them as VS.NET propjects makes upgrades / additions easier. Like upgrading to a new version of Lucene.Net, or adding missing declarations to some pretty hugh Win32 native interop projects.

If possible, I would try to keep each customer within their own repository. My reasoning for this is twofold.

One - A repository is a resource which access is controlled by the server. The more people you place within one repository means there is more contention when locking files ore making changes. The more people working within one repository may lead to small delays during serialized transactions.

Two - Less security issues. If each customer is in their own repository, you do not have to worry about setting security rights on folders. This is especially important when sharing folders. Since each repository would be isolated, this is not an issue.

The drawback to this setup would come when you want to share the SAME version of a library for multiple customers. Assuming you want to maintain only one code base for a library, sharing a project would be desirable (again assuming changes in one are acceptable to the other). In this case, you may want to place projects like these into one repository.

THONA wrote:* Licensing. I see the licenses. There is one thing I do not like. With Sourcegear I had the idea that when we move we could make limited licenses available for our customers. Limited as in "no checkout, no changes". What for? Well, they could grab copies of their source cheaply. Right now (Sourcesafe) we did so by using a tool similar to SourceOffSite - two installations, one for our developers, one with 5 licenses that our customers connect to. Keeping licenses costs down is something critical on those - it is more a service. There is no offer for this and no plan for "read only" licenses in Vault, right? And no, shadow directories are not an option. They are more a pain - with them you can not grab all changes in a source-hierarchy fast. This would also allow customers to be able to get "up to the minute" versions of developments - something important for us. Please note that a "guest" account would not really suffice - we need named accounts, due to directory security.

Sorry, there is not a license for this right now.

Do your customer's already have a valid VSS license? If not, then Vault's license / pricing is remarkably less expensive than SourceSafe, which runs about $500 USD / license.

In any even, I've placed a Request in your name to investigate creating a new license type for these types of situations.

THONA wrote:* So far so good ar ethere any plans to incorporate a backup/restore feature like sourcesafe has it for infividual "projects"? We found customers really liked it that at the end of their project we could ship them something they can import into sourcesafe and just see how things changed.

Yes. This feature is currently scheduled for release in Vault 4.0

THONA · Post by **THONA** » Sun Mar 20, 2005 12:20 am

Do your customer's already have a valid VSS license?

Yes.

One last word - when is SourceSafe 3.1 due? Like so mny other shops (hehe) we are using Whidbey in production right now (yes, happens - we start moving frameworks over so that we are ready, as wel las starting some long term .NET 2.0 projects).

THONA · Post by **THONA** » Sun Mar 20, 2005 12:21 am

Oh, and another one.

The import tool takes ages (days) on our archive.

What exactly is the bottleneck there? This ois just out of curiosity. I run everything on one syste, with sql server's hd's different from the ones used for sourcesafe. The CPU is not really moving high, memory is not an issue. So - what is it? Is SourceSafe so slow?

dan · Post by **dan** » Sun Mar 20, 2005 8:51 am

We should have Vault 3.1 ready in a couple of months, with a beta out before then.

The import takes a long time because we rely on the VSS COM component, which can be slow. Also, it just takes a long time to process years worth of data.

THONA · Post by **THONA** » Mon Mar 21, 2005 12:24 am

I hate to tell you, but a couple of months sounds VERY far out for people like me who are pressed to use Whidbey in production NOW

Ok, so - what is your assumed best approach for import? There is the most likely performance block? Sourcesafe hard disc?

My current setup is:

* Vault and sourcesfe on one server (our main internal server), with the vault SQL Server being on two hard discs (data, log) and Sourcesafe on a software RAID 5.
* To get performane up I could plug in a separate hard and movesourcesafe over there.

If there ANYTHING I can do to speed up the import process? Someone told me to export the projects and reimport them into a new sourcesafe database. Is read performance critical on the sourcesafe side, for the type of processing you make on sourcesafe?

lbauer · Post by **lbauer** » Mon Mar 21, 2005 9:03 am

We have tips for a successful import at this link:

http://support.sourcegear.com/viewtopic.php?t=7

If you have a very large database, you might want to consider importing it in chunks, rather than the whole thing at once.

lbauer · Post by **lbauer** » Mon Mar 21, 2005 9:14 am

To respond to your concern about Whidbey:

You can still use Whidbey without integrating it with Vault. Use the Vault GUI client for file operations like get, checkout, add, checkin, etc. Then do your development in Whidbey.

http://support.sourcegear.com/viewtopic.php?t=195

Guest · Post by **Guest** » Mon Mar 21, 2005 10:12 am

Thanks for the speed-tips. VERY usefull. I will go this way.

Regarding Whidbey - what about ptuting out a Teh Preview of Vault 3.1?

SourceGear Support

Wvaluating Vault for a move from SourceSafe

Wvaluating Vault for a move from SourceSafe

Re: Wvaluating Vault for a move from SourceSafe