SOS does not honor pinned files
Moderator: SourceGear
-
- Posts: 5
- Joined: Wed Mar 28, 2007 2:14 pm
SOS does not honor pinned files
I have projects in source safe that are pinned, branched, shared for further development.
When I use SOS to get latest or to look for differences in such projects, pinned files are replaced by newer source safe files. That should not happen, and in source safe it does not happen.
Why does it happen in SOS?
When I use SOS to get latest or to look for differences in such projects, pinned files are replaced by newer source safe files. That should not happen, and in source safe it does not happen.
Why does it happen in SOS?
I just double checked on it's pin function and didn't get the same results. Since you have shares and branches going on and I didn't involve those, can you tell me exactly the steps you took leading up to this?
Was the file you are trying to get the pinned version of in a different share or branch or was it a version from before the branch occurred?
Was the file you are trying to get the pinned version of in a different share or branch or was it a version from before the branch occurred?
-
- Posts: 5
- Joined: Wed Mar 28, 2007 2:14 pm
I used the VSS Share, Pin, Branch to create a new project. In the new project I branched some files so that I could add fixes, also in VSS.Beth wrote:I just double checked on it's pin function and didn't get the same results. Since you have shares and branches going on and I didn't involve those, can you tell me exactly the steps you took leading up to this?
Was the file you are trying to get the pinned version of in a different share or branch or was it a version from before the branch occurred?
When I use SOS to access the project, it shows a different icon for branched and pinned files. However, it does not give me the correct contents for the files.
For example, I have a file Recipe.cpp that was pinned at version 134 on January 26, 2007. Since then that file has moved to version 143 in the main path, but it should still be v134 in the share/pin/branch project. When I work with it in VSS, that is what I get.
When I look at Recipe.cpp through SOS, it tells me that the remote version is 134 but the local version is v143. The remote date is Jan 26, 2007 but the local date is 3/28/2007. I think the local date is correct because I just created a new working directory yesterday and filled it with a zip of the VSS files. I had to do that because when I did a get latest version with SOS, it overlaid the pinned files with the newer files from the main path - which is not right.
When I do a Show Differences with SOS, the left panel displays the contents of v143 and points out changes. It should be showing differences with respect to v134, the pinned version.
I am sure you understand that unless I find a solution to this problem, then I cant use SOS to work on service packs, bug fixes, etc, which is something we often have to do.
While we have been able to use SOS successfully for about a year now, and have found it quite helpful for remote development, this problem is causing me to lose confidence since it is clear that SOS does not always show the same file contents as VSS.
If there is some way for me to show you what I have done, or to capture logs, etc, to show what is on my screen, please let me know.
- Attachments
-
- VSS View of Recipe.cpp.png (33.78 KiB) Viewed 11062 times
-
- SOS View of Rrecipe.cpp
- (58.42 KiB) Downloaded 659 times
So that I can figure out what's happening here, I still have more questions.
What version of SOS are you using?
What is your Automation Component Version?
Another person here tried it and when she branches after the pin, it stays on the version she pinned at.
To make sure I fully understand this, the file that's at the incorrect version was pinned right before the branch, right? In the trunk it's at version 143 and the branch has the one that is supposed to be at version 137.
Have you tried a Get on the branched folder out to a different area than the working folder and checked to see what the contents are? Could you try that and let me know what it puts out in that other folder?
What version of SOS are you using?
What is your Automation Component Version?
Another person here tried it and when she branches after the pin, it stays on the version she pinned at.
To make sure I fully understand this, the file that's at the incorrect version was pinned right before the branch, right? In the trunk it's at version 143 and the branch has the one that is supposed to be at version 137.
Have you tried a Get on the branched folder out to a different area than the working folder and checked to see what the contents are? Could you try that and let me know what it puts out in that other folder?
-
- Posts: 5
- Joined: Wed Mar 28, 2007 2:14 pm
I created a new folder and did a Get of the project with the pinned folders. 140 files, out of a total of about 800 files in the get are incorrect.
SOS is getting the current files instead of the pinned versions of the files.
One of the 140 incorrect files is Recipe.cpp, which I discussed in an earlier post. Recipe.cpp is at v143 in the trunk and 134 in the branch. When I get the pinned version into the new folder, I get v143, not v134. The same problem is occuring with the other files that I have checked (I have not checked all 140 wrong files).
You assed for the Automation Component Version. I looked into your instructions for locating the information, but I am not sure which of the three computers is the SOS Server that you want me to check. We have VSS 6.0 installed on one computer that is not accessible via an external IP address. I access SOS via a second computer that is externally available via the 8080 port. Should I ckeck the automation version component on the computer with VSS, the computer with the external IP address, or on my remote computer?
The ssapi.dll on the computer with VSS 6 is 6.0.81.69
The ssapi.dll on my remote computer is v5.1.2600.2180.
If you need the version on the external IP computer, I will need to contact headquarters since I cannot access the files on that computer remotely.
SOS is getting the current files instead of the pinned versions of the files.
One of the 140 incorrect files is Recipe.cpp, which I discussed in an earlier post. Recipe.cpp is at v143 in the trunk and 134 in the branch. When I get the pinned version into the new folder, I get v143, not v134. The same problem is occuring with the other files that I have checked (I have not checked all 140 wrong files).
You assed for the Automation Component Version. I looked into your instructions for locating the information, but I am not sure which of the three computers is the SOS Server that you want me to check. We have VSS 6.0 installed on one computer that is not accessible via an external IP address. I access SOS via a second computer that is externally available via the 8080 port. Should I ckeck the automation version component on the computer with VSS, the computer with the external IP address, or on my remote computer?
The ssapi.dll on the computer with VSS 6 is 6.0.81.69
The ssapi.dll on my remote computer is v5.1.2600.2180.
If you need the version on the external IP computer, I will need to contact headquarters since I cannot access the files on that computer remotely.
We need to know the version of the ssapi.dll file on the SOS Server machine. If you're not sure which machine that is, check with your system administrator.
The SOS Server communicates with the VSS database via the SourceSafe automation component (ssapi.dll). The version of the ssapi.dll affects how the SOS Server works. Certain ssapi.dll versions work better than others with SOS Server.
The reason we need to know the version of the ssapi.dll is to determine whether the ssapi.dll is causing the problem.
The SOS Server communicates with the VSS database via the SourceSafe automation component (ssapi.dll). The version of the ssapi.dll affects how the SOS Server works. Certain ssapi.dll versions work better than others with SOS Server.
The reason we need to know the version of the ssapi.dll is to determine whether the ssapi.dll is causing the problem.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
- Posts: 5
- Joined: Wed Mar 28, 2007 2:14 pm
Thanks. That's an older version of VSS -- the very first version of VSS 6.0, I think.
We need a couple more bits of information:
-- what version of SOS client and server are you using?
-- If you look at the file list in the SOS Client, does the file have a pin icon next to it, like it does in VSS?
We need a couple more bits of information:
-- what version of SOS client and server are you using?
-- If you look at the file list in the SOS Client, does the file have a pin icon next to it, like it does in VSS?
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
- Posts: 5
- Joined: Wed Mar 28, 2007 2:14 pm
First, in the SOS GUI Client, make sure that "Display Status of Pinned Files" is checked under Tools->Options->View. I was able to reproduce what you are seeing when this was not checked. I noted that you are seeing the shared files, but not the pin in SOS.
To properly update the client, after you change this setting, close the SOS Client and restart the SOS Server. This will send new pin information.
If this does not resolve the problem, it could be due to the VSS Automation Component, and/or your version of SOS.
The next steps would be:
1) Update your version of the VSS Automation component on the SOS Server machine. You are using an old version which may not work well with the current version of SOS. I'd suggest using VSS 6.0c Hotfix version, which is a very stable version. You can download it here:
http://download.sourcegear.com/files/vss_60c_hotfix.zip
Replace the contents of the VSS\Win32 directory on the SOS Server machine with the contents of this archive.
2) Update to SOS 4.2, client and server. This is a free upgrade. You can download SOS from our web site:
http://www.sourcegear.com/sos/index.html
If after all three of these steps, you see the same behavior, there could be minor database corruption in VSS that is not providing the proper pin information to the SOS Server. In that case, running Analyze on your VSS database may help. Or may may need to see a copy of your database or project archive to debug the problem here.
To properly update the client, after you change this setting, close the SOS Client and restart the SOS Server. This will send new pin information.
If this does not resolve the problem, it could be due to the VSS Automation Component, and/or your version of SOS.
The next steps would be:
1) Update your version of the VSS Automation component on the SOS Server machine. You are using an old version which may not work well with the current version of SOS. I'd suggest using VSS 6.0c Hotfix version, which is a very stable version. You can download it here:
http://download.sourcegear.com/files/vss_60c_hotfix.zip
Replace the contents of the VSS\Win32 directory on the SOS Server machine with the contents of this archive.
2) Update to SOS 4.2, client and server. This is a free upgrade. You can download SOS from our web site:
http://www.sourcegear.com/sos/index.html
If after all three of these steps, you see the same behavior, there could be minor database corruption in VSS that is not providing the proper pin information to the SOS Server. In that case, running Analyze on your VSS database may help. Or may may need to see a copy of your database or project archive to debug the problem here.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager