Checkout Error "Operation Failed: $/Project/File"
Moderator: SourceGear
Checkout Error "Operation Failed: $/Project/File"
Hi,
I am getting the below message while checking out a file using SourceOffsite.
Operation Failed : $/Project/File
I have confirmed that, other VSS projects offered by the same Sourceoffsite server do not have any such problem.
Due to this reason, I am forced to use the 'Keep checked out' option during checkin. Of course the first time, I have to go to the remote site using some tools like Netmeeting / Timbuktu / VNC and Check them out using VSS. This is a badly restricting our development process.
Pls let me know if there is a solution to this.
Thanks in advance (really many many thanks)
MVN Prasad.
I am getting the below message while checking out a file using SourceOffsite.
Operation Failed : $/Project/File
I have confirmed that, other VSS projects offered by the same Sourceoffsite server do not have any such problem.
Due to this reason, I am forced to use the 'Keep checked out' option during checkin. Of course the first time, I have to go to the remote site using some tools like Netmeeting / Timbuktu / VNC and Check them out using VSS. This is a badly restricting our development process.
Pls let me know if there is a solution to this.
Thanks in advance (really many many thanks)
MVN Prasad.
I'd like more information on what cannot be checked out. Is it a particular file or various files?
Are you having a problem checking out files in just one project?
Can other SOS users check out the same file(s)?
What version of SOS are you using?
It might be helpful to see a copy of the SOS log file which shows the time of the checkout. Enable debug logging:
SOS 4.0:
http://support.sourcegear.com/viewtopic.php?t=463
or
SOS 3.5.x -- In the SOS Server Manager, under the debug tab, check the box to allow verbose logging.
Perform the operations that are failing, then email me a copy of the log.txt file in the SOS Server directory. Let me know the time in the log and the username that corresponds with the failed operation.
Are you having a problem checking out files in just one project?
Can other SOS users check out the same file(s)?
What version of SOS are you using?
It might be helpful to see a copy of the SOS log file which shows the time of the checkout. Enable debug logging:
SOS 4.0:
http://support.sourcegear.com/viewtopic.php?t=463
or
SOS 3.5.x -- In the SOS Server Manager, under the debug tab, check the box to allow verbose logging.
Perform the operations that are failing, then email me a copy of the log.txt file in the SOS Server directory. Let me know the time in the log and the username that corresponds with the failed operation.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Linda,
Thanks for your response.
Pls find answers to your questions.
I'd like more information on what cannot be checked out. Is it a particular file or various files?
On ALL FILES of some VSS Database(s). Few other VSSDB on the same server works fine.
Are you having a problem checking out files in just one project?
As mentioned above, this problem is only seen in some VSS databases, others are working fine.
Can other SOS users check out the same file(s)?
No. Same problem for everyone.
What version of SOS are you using?
Sever 2.0, Client 3.5.1, but the same problem was seen in 2.x client as well.
It might be helpful to see a copy of the SOS log file which shows the time of the checkout. Enable debug logging, Perform the operations that are failing, then email me a copy of the log.txt file in the SOS Server directory. Let me know the time in the log and the username that corresponds with the failed operation
Corresponding to the Checkout operation, I see a "CreateProcess" Entry in the log file. No other information in the log file.
Hope I would get to know something from you about how to rectify this serious problem for us.
Thanks a lot,
MVN Prasad.
Thanks for your response.
Pls find answers to your questions.
I'd like more information on what cannot be checked out. Is it a particular file or various files?
On ALL FILES of some VSS Database(s). Few other VSSDB on the same server works fine.
Are you having a problem checking out files in just one project?
As mentioned above, this problem is only seen in some VSS databases, others are working fine.
Can other SOS users check out the same file(s)?
No. Same problem for everyone.
What version of SOS are you using?
Sever 2.0, Client 3.5.1, but the same problem was seen in 2.x client as well.
It might be helpful to see a copy of the SOS log file which shows the time of the checkout. Enable debug logging, Perform the operations that are failing, then email me a copy of the log.txt file in the SOS Server directory. Let me know the time in the log and the username that corresponds with the failed operation
Corresponding to the Checkout operation, I see a "CreateProcess" Entry in the log file. No other information in the log file.
Hope I would get to know something from you about how to rectify this serious problem for us.
Thanks a lot,
MVN Prasad.
We don't get too many support issues for SOS 2.0, as this version is several years old. However, if it worked previously, then the checkout issue may be related to a problem with the VSS database. Has something changed recently? Did you change the version of VSS being used on the SOS Server machine? Were there configuration changes?
See this KB article for suggestions:
http://support.sourcegear.com/viewtopic.php?t=128
See this KB article for suggestions:
http://support.sourcegear.com/viewtopic.php?t=128
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Linda,
Thanks for you looking into this problem for me. See replies to your questions.
We don't get too many support issues for SOS 2.0, as this version is several years old. However, if it worked previously, then the checkout issue may be related to a problem with the VSS database. Has something changed recently? Did you change the version of VSS being used on the SOS Server machine? Were there configuration changes?
1. It never worked. I have been seeing this problem ever since having a v2.0 client with a v2.0 server.
2. I remember faintly that we might have switched from VSS 5.0 to VSS 6.0 on the SOS server machine. BUT, the same thing is applicable for those projects which worked FINE BEFORE and even now AFTER the change of VSS version.
3. If you think changing of VSS version on the server is the reason, do you know of any workarounds / ways to fix this problem now? like reinstall SOS etc?
3. Can you explain what you meant by configuration changes in your question above ?
4. I already looked at the article you gave i.e. http://support.sourcegear.com/viewtopic.php?t=128 , the solutions in there doesnt seem to work in my case.
5. Did that info about the log help?
Thanks a lot once again. I am hopeful that you will find a solution for me.
MVN Prasad.
Thanks for you looking into this problem for me. See replies to your questions.
We don't get too many support issues for SOS 2.0, as this version is several years old. However, if it worked previously, then the checkout issue may be related to a problem with the VSS database. Has something changed recently? Did you change the version of VSS being used on the SOS Server machine? Were there configuration changes?
1. It never worked. I have been seeing this problem ever since having a v2.0 client with a v2.0 server.
2. I remember faintly that we might have switched from VSS 5.0 to VSS 6.0 on the SOS server machine. BUT, the same thing is applicable for those projects which worked FINE BEFORE and even now AFTER the change of VSS version.
3. If you think changing of VSS version on the server is the reason, do you know of any workarounds / ways to fix this problem now? like reinstall SOS etc?
3. Can you explain what you meant by configuration changes in your question above ?
4. I already looked at the article you gave i.e. http://support.sourcegear.com/viewtopic.php?t=128 , the solutions in there doesnt seem to work in my case.
5. Did that info about the log help?
Thanks a lot once again. I am hopeful that you will find a solution for me.
MVN Prasad.
Hi,
(I am referring to the TWO entries just above this one in this thread.)
The solution posted by "Guest" for this original problem (which I started off in this thread) DIDN'T work for me.
Apparantly, the problem "Guest" mentioned was SIMILAR but not SAME.
I wanted to mention this so that my problem is still OPEN as far as this thread is concerned.
"Guest" was lucky, to get a solution to his problem.
I am still hopeful that I may get a solution to this.
Thanks in advance,
MVN Prasad
(I am referring to the TWO entries just above this one in this thread.)
The solution posted by "Guest" for this original problem (which I started off in this thread) DIDN'T work for me.
Apparantly, the problem "Guest" mentioned was SIMILAR but not SAME.
I wanted to mention this so that my problem is still OPEN as far as this thread is concerned.
"Guest" was lucky, to get a solution to his problem.
I am still hopeful that I may get a solution to this.
Thanks in advance,
MVN Prasad
I'm not familiar with the "create process" message. It may have been something in SOS 2.0 logging.
What version of VSS client is on the SOS Server machine? Verify that this matches the version of the SOS Server installed. For instance, SOS 3.x had SOS Server versions for both VSS 5 and VSS 6. This was because the automation component was different for these versions of VSS.
You should be able to check the version in the SOS Server manager. I don't have SOS 2.0, but in 3.0 the info was in the General tab.
Another possibility is minor database corruption is causing a problem for SOS.
See this KB article for more info:
http://support.sourcegear.com/viewtopic.php?t=50
What version of VSS client is on the SOS Server machine? Verify that this matches the version of the SOS Server installed. For instance, SOS 3.x had SOS Server versions for both VSS 5 and VSS 6. This was because the automation component was different for these versions of VSS.
You should be able to check the version in the SOS Server manager. I don't have SOS 2.0, but in 3.0 the info was in the General tab.
Another possibility is minor database corruption is causing a problem for SOS.
See this KB article for more info:
http://support.sourcegear.com/viewtopic.php?t=50
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Well, finally I myself got to know whats happening.
For checkout to work, Looks like SOS expects the "win32" subdirectory under each VSS database's main folder. This wasn't there because in our case because, if there were say 100 databases, each of them having "win32" subdirectory was meaningless (~9mb each). VSS didn't need such multiple copies of "win32" directory, so they were taken off. (i.e. just the data, users, temp folders exist per VSS database)
Now, for the project I was having the problem, I placed a copy of the "win32" folder from another existing project and it is working fine.
BUT, how does checkin/create etc work even if "win32" directory wasnt there? I think SoS must have an answer...
Thanks,
MVN Prasad.
For checkout to work, Looks like SOS expects the "win32" subdirectory under each VSS database's main folder. This wasn't there because in our case because, if there were say 100 databases, each of them having "win32" subdirectory was meaningless (~9mb each). VSS didn't need such multiple copies of "win32" directory, so they were taken off. (i.e. just the data, users, temp folders exist per VSS database)
Now, for the project I was having the problem, I placed a copy of the "win32" folder from another existing project and it is working fine.
BUT, how does checkin/create etc work even if "win32" directory wasnt there? I think SoS must have an answer...
Thanks,
MVN Prasad.
The Win32 directory is the directory used by the VSS Client and Admin Tool. If you create a database with the Admin Tool, it creates data, temp, and users folders for the database, but not a Win32 directory.
The SOS Server uses the SourceSafe Automation Component (ssapi.dll) from the VSS Client Win32 directory to communicate with the database.
So there's really only one important VSS Win32 directory -- the one on the same machine as the SOS Server.
The SOS Server uses the SourceSafe Automation Component (ssapi.dll) from the VSS Client Win32 directory to communicate with the database.
So there's really only one important VSS Win32 directory -- the one on the same machine as the SOS Server.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Well, if so, why was It NOT working if I didn't have a win32 directory within the Sourcesafe database parent directory? My server is quite old, v2.0, so in that version it might be looking for the win32 directory within the VSS project database, and NOT from VSS product installation directory on the server.
Anyway, I am happy it is working.
mvnprasad
Anyway, I am happy it is working.
mvnprasad