coming from vss 6.0d
Moderator: SourceGear
coming from vss 6.0d
Hello,
I have just started my evaluation of your product. My current source control solution is VSS 6.0d.
It seems like I can't do an import or a handoff from vss6.0d is that correct?
If so, what course of action fo you recommend for someone trying to upgrade from vss 6.0d.
Regards,
Francisco
I have just started my evaluation of your product. My current source control solution is VSS 6.0d.
It seems like I can't do an import or a handoff from vss6.0d is that correct?
If so, what course of action fo you recommend for someone trying to upgrade from vss 6.0d.
Regards,
Francisco
Re: coming from vss 6.0d
Depends on the full version of the component. There's several versions for 6.0d. The one that was tested is 6.0.98.48.
Use the instructions posted here, http://support.sourcegear.com/viewtopic.php?t=1510, to find which version of the ssapi.dll that you have. If you are on a 64-bit server, then the automation component will be found under the WOW6432 node in the registry.
Also, if this is a 64-bit server, then some changes need to be made before you can hand-off.
Use the instructions posted here, http://support.sourcegear.com/viewtopic.php?t=1510, to find which version of the ssapi.dll that you have. If you are on a 64-bit server, then the automation component will be found under the WOW6432 node in the registry.
Also, if this is a 64-bit server, then some changes need to be made before you can hand-off.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: coming from vss 6.0d
Hello,
I have 32 bit visual sourceSafe 6.0d 6.0.98.48.
Is this the compatible version or the wrong one for import/hand-off into vault?
Regards,
Francisco
I have 32 bit visual sourceSafe 6.0d 6.0.98.48.
Is this the compatible version or the wrong one for import/hand-off into vault?
Regards,
Francisco
Re: coming from vss 6.0d
The version 6.0.98.48 is fine for hand off.
If you're performing a full import, then you would want 6.0.96.40.
We also support VSS 2005 sp1.
Which are you wanting to do, a hand-off or import?
What is your server operating system? Is it 64-bit or 32-bit?
If you're performing a full import, then you would want 6.0.96.40.
We also support VSS 2005 sp1.
Which are you wanting to do, a hand-off or import?
What is your server operating system? Is it 64-bit or 32-bit?
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: coming from vss 6.0d
I think I would prefer a full import (so that I can just get rid of sourceSafe).
Currently both the vss server and the vault server are 32 bit.
What are my options?
Regards,
Francisco
Currently both the vss server and the vault server are 32 bit.
What are my options?
Regards,
Francisco
Re: coming from vss 6.0d
The place to start for VSS import information is the following articles:
Tips for a Successful VSS Import
Options for a VSS Import
Importing a solution or project that uses IDE Integration
Finding the full VSS Import Tool for Vault 5.0
The first article will have a link to the preferred automation component for importing.
Tips for a Successful VSS Import
Options for a VSS Import
Importing a solution or project that uses IDE Integration
Finding the full VSS Import Tool for Vault 5.0
The first article will have a link to the preferred automation component for importing.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: coming from vss 6.0d
Beth,
I read those articles before I started this support call.
Both of the first two articles state:
"Do not use SourceSafe 6.0d or non-English language versions of SourceSafe."
So, what do you recommend for someone who is using VSS 6.0.98.48?
You did say previously that 6.0.98.48 is fine for hand off (do you need to update the second document with this information?).
Should I only consider hand-off? Is import a non-starter because I have VSS 6.0.98.48?
Thanks for your help.
Francisco
I read those articles before I started this support call.
Both of the first two articles state:
"Do not use SourceSafe 6.0d or non-English language versions of SourceSafe."
So, what do you recommend for someone who is using VSS 6.0.98.48?
You did say previously that 6.0.98.48 is fine for hand off (do you need to update the second document with this information?).
Should I only consider hand-off? Is import a non-starter because I have VSS 6.0.98.48?
Thanks for your help.
Francisco
Re: coming from vss 6.0d
In the first KB article I posted the 6.0c automation component to use for imports. There is an instructions document in the zip file you download.
So that I can better answer your questions, can you tell me why you are wanting import over hand-off? Are you still branching from older versions or is it just to have the data present in one place?
How large is your current VSS database? If it's very large, you would find that hand-off might be a better route.
There are some advantages to using hand-off. Your database starts out smaller and is likely to be more responsive. Hand-off avoids potential inconsistencies that VSS could send over. Also, it's not common for users to be accessing and editing data that's more than a few months old.
So that I can better answer your questions, can you tell me why you are wanting import over hand-off? Are you still branching from older versions or is it just to have the data present in one place?
How large is your current VSS database? If it's very large, you would find that hand-off might be a better route.
There are some advantages to using hand-off. Your database starts out smaller and is likely to be more responsive. Hand-off avoids potential inconsistencies that VSS could send over. Also, it's not common for users to be accessing and editing data that's more than a few months old.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: coming from vss 6.0d
Beth,
In the first KB article I posted the 6.0c automation component to use for imports. There is an instructions document in the zip file you download.
- The zip file for the import tool?
So that I can better answer your questions, can you tell me why you are wanting import over hand-off? Are you still branching from older versions or is it just to have the data present in one place?
- Really I just want to get rid of SourceSafe if possible...If I have a new tool why keep the old one? From what I understand about hand-off I need to keep sourceSafe running.
Our convention is to create a new branch everytime we have a new version of our software (the instruction is "Share and Branch" in sourceSafe from the previous version. We do this for all of the code). At the end of the day our greatest concern is to be able to continue to do diffs to previous versions and to be able to read old comments.
How large is your current VSS database? If it's very large, you would find that hand-off might be a better route.
-It is currently about 7 GB in size. I got that information by checking the size of the data directory on the vss server. Is that the information you were looking for?
There are some advantages to using hand-off. Your database starts out smaller and is likely to be more responsive. Hand-off avoids potential inconsistencies that VSS could send over. Also, it's not common for users to be accessing and editing data that's more than a few months old.
- I ran the "Analyze" and had no issues. We don't edit any files outside of the current branch (current version). We rarely access any branch outside of the current branch or the previous branch/version.
Thanks.
Francisco
In the first KB article I posted the 6.0c automation component to use for imports. There is an instructions document in the zip file you download.
- The zip file for the import tool?
So that I can better answer your questions, can you tell me why you are wanting import over hand-off? Are you still branching from older versions or is it just to have the data present in one place?
- Really I just want to get rid of SourceSafe if possible...If I have a new tool why keep the old one? From what I understand about hand-off I need to keep sourceSafe running.
Our convention is to create a new branch everytime we have a new version of our software (the instruction is "Share and Branch" in sourceSafe from the previous version. We do this for all of the code). At the end of the day our greatest concern is to be able to continue to do diffs to previous versions and to be able to read old comments.
How large is your current VSS database? If it's very large, you would find that hand-off might be a better route.
-It is currently about 7 GB in size. I got that information by checking the size of the data directory on the vss server. Is that the information you were looking for?
There are some advantages to using hand-off. Your database starts out smaller and is likely to be more responsive. Hand-off avoids potential inconsistencies that VSS could send over. Also, it's not common for users to be accessing and editing data that's more than a few months old.
- I ran the "Analyze" and had no issues. We don't edit any files outside of the current branch (current version). We rarely access any branch outside of the current branch or the previous branch/version.
Thanks.
Francisco
Re: coming from vss 6.0d
It's in the zip file for the 6.0c automation component found in the very first article I posted. Here is the link to the automation component: http://download.sourcegear.com/files/vss_60c_hotfix.zip. Read the file called hotfix.txt.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: coming from vss 6.0d
Beth,
Since you had said that vss 6.0.98.48 was fine for handoff I decided to give it a try.
I created a small sample vss database by archiving a project from our main vss database and restoring it in my sample vss database.
I ran analyze on my sample database and no errors were reported.
When I ran the handoff on the sample database (with one project) the folder structure was created in vault fine but none of the files were processed correctly.
Below is a portion of the vault server log...
----8/20/2010 12:54:18 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Login
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception getting file from VSS: Version not found
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception creating add request for $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf: Could not add version 1 of $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled at VaultServiceAPILib.VSSOperations.CreateRequestAddFile(String vsspath, String vaultpath, Int32 version)
at VaultServiceAPILib.VSSOperations.ImportProjectRecursive(String vssPath, String vaultPath, Boolean createRoot, Int32 importRunID, ArrayList& requests)
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Handoff Error: Exception creating add request for $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf: Could not add version 1 of $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception getting file from VSS: Version not found
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception creating add request for $/Builds/TeamSuite/5.7.0 Full Install/configuration.xml: Could not add version 1 of $/Builds/TeamSuite/5.7.0 Full Install/configuration.xml
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled at VaultServiceAPILib.VSSOperations.CreateRequestAddFile(String vsspath, String vaultpath, Int32 version)
at VaultServiceAPILib.VSSOperations.ImportProjectRecursive(String vssPath, String vaultPath, Boolean createRoot, Int32 importRunID, ArrayList& requests)
Any ideas? Is this an automation issue?
Francisco
Since you had said that vss 6.0.98.48 was fine for handoff I decided to give it a try.
I created a small sample vss database by archiving a project from our main vss database and restoring it in my sample vss database.
I ran analyze on my sample database and no errors were reported.
When I ran the handoff on the sample database (with one project) the folder structure was created in vault fine but none of the files were processed correctly.
Below is a portion of the vault server log...
----8/20/2010 12:54:18 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Login
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception getting file from VSS: Version not found
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception creating add request for $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf: Could not add version 1 of $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled at VaultServiceAPILib.VSSOperations.CreateRequestAddFile(String vsspath, String vaultpath, Int32 version)
at VaultServiceAPILib.VSSOperations.ImportProjectRecursive(String vssPath, String vaultPath, Boolean createRoot, Int32 importRunID, ArrayList& requests)
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Handoff Error: Exception creating add request for $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf: Could not add version 1 of $/Builds/TeamSuite/5.7.0 Full Install/Autorun.inf
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception getting file from VSS: Version not found
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled Exception creating add request for $/Builds/TeamSuite/5.7.0 Full Install/configuration.xml: Could not add version 1 of $/Builds/TeamSuite/5.7.0 Full Install/configuration.xml
----8/20/2010 12:58:10 AM admin--mccabe.entry.com(10.1.1.20)--SSL Disabled at VaultServiceAPILib.VSSOperations.CreateRequestAddFile(String vsspath, String vaultpath, Int32 version)
at VaultServiceAPILib.VSSOperations.ImportProjectRecursive(String vssPath, String vaultPath, Boolean createRoot, Int32 importRunID, ArrayList& requests)
Any ideas? Is this an automation issue?
Francisco
Re: coming from vss 6.0d
It's hard to say exactly what the issue is. It could be automation component, it could be something with the data, it could be something we haven't discovered yet.
Do you have require check-in comments or folder security turned on for the repository you are transferring to?
Do you see the items in your VSS database currently?
Here's something I found that has the potential to help if there's some inconsistency in the VSS database.
1) Create a new blank VSS database.
2) Perform an archive of the old database and restore it to the new one. I think there might be a limit on archive size, but you might also be able to do a few small ones and restore them
3) Restore the archive to the new database.
4) Run the following command via a command line for analyzing twice:
analyze -C -D -F -V4 C:\VSS\Data
But replace the path 'C:\VSS\Data' with the path to your new VSS database Data folder. If you still have any errors showing up after the second analyze pass, then those might not be fixable.
5) Try a new hand-off to a new blank repository. You can delete repositories with no negative affect on the other repositories, so you can feel free to make as many as you wish.
Do you have require check-in comments or folder security turned on for the repository you are transferring to?
Do you see the items in your VSS database currently?
Here's something I found that has the potential to help if there's some inconsistency in the VSS database.
1) Create a new blank VSS database.
2) Perform an archive of the old database and restore it to the new one. I think there might be a limit on archive size, but you might also be able to do a few small ones and restore them
3) Restore the archive to the new database.
4) Run the following command via a command line for analyzing twice:
analyze -C -D -F -V4 C:\VSS\Data
But replace the path 'C:\VSS\Data' with the path to your new VSS database Data folder. If you still have any errors showing up after the second analyze pass, then those might not be fixable.
5) Try a new hand-off to a new blank repository. You can delete repositories with no negative affect on the other repositories, so you can feel free to make as many as you wish.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support