SourceGear Support

Hi,
I am currently evaluating SourceGear. Our current source control is Visual Source Safe and we have automated our build process and all access to sourcesafe.
The first task that I have is to migrate all of our source to SourceGear. I am aware of the migration feature in SourceGear. This took >6 days. I have create my own migration take far less time.
I have been able to modify my SourceSafe class to work very well with the SourceGear API.
But I have 2 problems.
Problem 1
I need to modify the history of a file. This is due to my migration code.
a) Get sourcesafe "file" version 1
b) Add file to source gear (Sourcegear history shows the current date, I need to have it show the Sourcesafe date of the version transaction)

Then in simple terms
for each version in Sourcesafe file
Get user for the source safe history transaction
Login to sourcegear with that username
checkout sourcegear file
get sourcesafe file version overwriting the local Sourcegear file.
check into Sourcegear with comments (again the check in date shows the current date)

What I have tried is to modify my computers date and time for each transaction but that failed. Sourcegear must be using the Server Date and Time. Not my local computer time.

Do you have a suggestion for this problem.

Problem 2
Our Sourcesafe data base contains ~13000 binary files that are typically 4meg in size.
The files can have on upwards to 500 versions.
Now when I have run the migration software the SourceGear cache grew to 75gb and ate up all of my hard drive space.

I found that is a directory structure like this.
C:\Documents and Settings\user\Local Settings\Application Data\Sourcegear\Vault_1\Client\C772EA7B-BDBB-4A74-B409-163C46E6A11C\user\_sgvault\1308754875

C:\Documents and Settings\user\Local Settings\Application Data\Sourcegear\Vault_1\Client\C772EA7B-BDBB-4A74-B409-163C46E6A11C\user2\_sgvault\1308754875

C:\Documents and Settings\user\Local Settings\Application Data\Sourcegear\Vault_1\Client\C772EA7B-BDBB-4A74-B409-163C46E6A11C\user3\_sgvault\1308754875


It seems that for each login a new directory structure is created. These directories can contain tens of gigs for files.
My question:
Is there a way programmatically I can clear the cache for each user when a new user is logged in?
Sorry for the long winded explanation.

Dave

Hi Dave,

You are correct in your assessment of the problems that you are facing. First, I would advise you to look at our Handoff feature, which can import a smaller set of history much quicker, and give you integrated access to your VSS history.

As for your import, there is no regular method for altering the date/time of a commit.

You are also correct in your diagnosis of the multiple cache folders, one per user. There is no workaround for that, either.

In general, the things you're asking for help on are far outside the scope of regular usage. As for your 6 day import, have you contacted our support team for help?

Jeremy,

Thanks for the confirmation.

We require that we have all versions of files ever checked in, so we can recreate any version of software that we built.
So the type of transfer that I am doing is the only way that the source safe to source gear migration can occur.
I will get around the problems with a brute force approach of changing the server date and time, an each time the user is changed I will delete the cache directory of the old user.

We currently have 4 source safe databases that we need to import.
There are several others (much older information) that may need to be imported at a later date.
So, if I were make a suggestion for the API development team. I would suggest that you add the ability to programmatically change the history date, and to limit the cache size.

Thanks again.

Dave

The beauty of Handoff is that we don't require that you change how you access older versions. You can keep VSS around to do VSS label or history gets. Your old build scripts don't have to change at all. History is history, and you can still get it when you need it. Of course, you can still see file history directly in Vault, and fetch old versions of the file without loading VSS. My feeling is that you can spend a month writing your custom import to get around VSS corruption, but it's not worth it for the few number of times that you'll reference the old data. And don't even get me started on importing VSS labels.

We've logged a feature request to change times/dates after the fact. It's unlikely to change, since you are the first person in the history of Vault who has wanted to rewrite our full importer. You did see that we still have the full import around in 5.0, right? http://support.sourcegear.com/viewtopic ... 13&t=12240