I am running SOS server 4.0.2 on a single processor Win2k server SP4 (also the VSS server), VSS 6.0d; SOS client 4.0.2 on Win XP SP2, VS 2005
I have a 9 project solution that I and another developer have been working on, using SOS, for some time with few problems.
A couple of days ago, my partner had many files checked out in 2 of the projects and I had a few of these also checked out. We both made changes; i checked in everything and then so did he. No conflict messages appeared.
But now, when I open the solution in VS, certain files (I believe its the set of files my partner had checked out) suddenly get a status of Needs Merge, and the local and remote versions of these files as viewed in the SOS client are different. I don't have any files checked out. If I compare my local files to those in VSS, they are not different. Doing a Get Latest (recursive, with overwrite) from VS does not change the file status, even though the log shows that the files marked as Needs Merge are copied to my local machine (with a warning for each if I don't click the option dialog otherwise).
Closing VS and doing a Get Latest (recursive, with overwrite) from the SOS client on either the solution or the 2 effected projects, gets the same files, but then the status is cleared, and the local and remote versions match. But if i leave the SOS client open and then open the solution in VS, the status of these certain files in the SOS client is set back to Needs Merge, and the local version number is changed (to a lesser value than the remote version).
It would seem that VSS has some stale version information, but how can I straighten this out?
Thanks.
sticky "Needs Merge" issue
Moderator: SourceGear
It sounds like one of the applications involved could be looking in a different area than the other for local files. Check what you have set for a working folder in VS and see if either VSS or SOS have something different listed. If everything seems OK there, then I'd suggest closing all the applications and clearing the client side cache. More information on that is listed here: http://support.sourcegear.com/viewtopic.php?p=5361
Is there a chance that the file is being edited and uploaded before you are aware of it? You may wish to take a look at the history of the file to see what's going on.
If this doesn't solve it, then I'll be asking for some log files next.
Is there a chance that the file is being edited and uploaded before you are aware of it? You may wish to take a look at the history of the file to see what's going on.
If this doesn't solve it, then I'll be asking for some log files next.
Hi Beth,
Thanks for responding.
Yes, VS, VSS and SOS all are set to the same working folders.
I read with interest the article you cite about the SOS cache files, but it does not say anything about how to "clear" the cache; it also does not mention how the "Needs Merge" status is arrived at.
So I tried this: closed VS, and did a get from SOS client; this puts everything back in sync. SOS client (and database1.sos) agree that local and remote versions are the same. For example:
File FMain.vb is at version 238. Its history shows that I checked in v237 yesterday at 7:20am, and my colleague checked in v238 at 10:44am. As I said, we had the file checked out simultaneously, and we both made changes. And it was merged correctly (v238 contains the changes i made from v236 to create v237).
Now, keeping the SOS client open, I open VS. While the solution is opened, database1.sos is written to but when all is said and done, it still says that FMain.vb is at v238. But the SOS client now says that it is at v237 locally and Needs Merge. The file history has not changed.
From VS, on FMain, i do a get, then a check-out, then a undo check-out. For each step, database1.sos is written to, but it remains with FMain.vb at v238, and the SOS client remains at v237 Needs Merge.
But then after I close VS and SOS client, database1.sos is written to and FMain now is shown with v237, and the date string (1158765393) is now modified.
For a giggle, I moved the databaseX.sos and index.sos files. The SOS client then sos a status of missing, so I set the working folders or each project and they are now "Unknown".
I then turned on the "uses crc to check unknon" option and did a refresh file list on each project. This put things looking OK in the SOS client.
Then I opened the solution in VS ... no change in the SOS client. Closed VS, again no change in the client.
So it looks like the problem is resolved. But it is something of a pain; there are many other projects that now must have their working folder set and refresh file list.
Thanks.
Thanks for responding.
Yes, VS, VSS and SOS all are set to the same working folders.
I read with interest the article you cite about the SOS cache files, but it does not say anything about how to "clear" the cache; it also does not mention how the "Needs Merge" status is arrived at.
So I tried this: closed VS, and did a get from SOS client; this puts everything back in sync. SOS client (and database1.sos) agree that local and remote versions are the same. For example:
File FMain.vb is at version 238. Its history shows that I checked in v237 yesterday at 7:20am, and my colleague checked in v238 at 10:44am. As I said, we had the file checked out simultaneously, and we both made changes. And it was merged correctly (v238 contains the changes i made from v236 to create v237).
Now, keeping the SOS client open, I open VS. While the solution is opened, database1.sos is written to but when all is said and done, it still says that FMain.vb is at v238. But the SOS client now says that it is at v237 locally and Needs Merge. The file history has not changed.
From VS, on FMain, i do a get, then a check-out, then a undo check-out. For each step, database1.sos is written to, but it remains with FMain.vb at v238, and the SOS client remains at v237 Needs Merge.
But then after I close VS and SOS client, database1.sos is written to and FMain now is shown with v237, and the date string (1158765393) is now modified.
For a giggle, I moved the databaseX.sos and index.sos files. The SOS client then sos a status of missing, so I set the working folders or each project and they are now "Unknown".
I then turned on the "uses crc to check unknon" option and did a refresh file list on each project. This put things looking OK in the SOS client.
Then I opened the solution in VS ... no change in the SOS client. Closed VS, again no change in the client.
So it looks like the problem is resolved. But it is something of a pain; there are many other projects that now must have their working folder set and refresh file list.
Thanks.
For clearing the cache, you only need to delete or rename the files it is using for the cache and SOS will create them. Once source control is integrated with VS, it's always best to perform all functions you can within VS as it can be particular about what it wants to do. When I'm working with it, I set my working folders from in there (even if it does call source control), perform my gets, etc.