3 problems with SOS 5.0.1

[andrewstanton]

Hi,

I have three problems to report with SOS 5.0.1.

Our setup is as follows:
- Server: Vista Ultimate 32-bit, VSS 2005 with latest patch, SOS 5.0.1 Server.
- Clients (used over both LAN and Internet): SOS 5.0.1


The first problem is that some files are repeatedly being set to the "unknown" status. If I get the contents of a project the file statuses are set properly, but if I then close the SOS client and reopen it the same files suddenly revert to "unknown" status and they lose their local version numbers. This appears only to be happening in projects/folders that have an underscore (e.g. "_include") or a full stop (e.g. "ASC.Program") in them (although I can't be sure the problem doesn't happen with other folder names).

SOS501_Unknown_Status.jpg (256.68 KiB) Viewed 21362 times

The second problem is to do with the Search feature when searching for missing files. I make sure I have done an entire Get Latest so that my local files are in sync with VSS, then I do a search for missing files (files with the status of "missing"), and the search returns a long list of files that are shown to be in completely the wrong project. The list is completely messed up, with files that belong in unrelated projects appearing in different project paths. And of course the status of these files are "missing" because they don't exist in the reported projects in the VSS database to begin with! I don't have a screen shot unfortunately at the moment.


The third problem appear to the related to the second problem, i.e. SOS is getting it's file/project list messed up somewhere. Often in the SOS client I'll browse to a project and find phantom files in there (files that exists elsewhere in the VSS database but are incorrectly being displayed in the wrong project folder!). These phantom files have the status of "missing", which of course makes sense as they don't belong there and have never been "got" to the local folder. If I Refresh File List on the project in question the phantom files disappear.

SOS501_Missing_Files_That_Dont_Exist.jpg (362.54 KiB) Viewed 21362 times

These issues, along with the "Visual Studio crashes upon wake from Hibernate when using the SOS plugin" (http://support.sourcegear.com/viewtopic ... 10&t=12787), are causing real problems for my source control, and seriously affecting productivity amongst my developers. Can you please let me know (based on reports of these problems from other users and from your own testing) when these bugs are likely to be fixed, as I need to make a decision whether to scrap SOS5 and reinstall our old SOS 4.2 environment, which I've used for years without a single problem!

Many thanks for your help in these matters,

Andrew Stanton.

[jclausius]

Andrew,

In regards to the hibernate issue, developers are currently underway looking at the issue.

As to the other problems posted here, these are the first reports of this kind of issue. I cannot say anything about them as nothing like this came up in our testing which did search for files of different status in different folders. I'll log all the issues and tackle them one at a time.

Once we have fixed the issues, we need to discuss the best manner to get the fixes into your hands.

[andrewstanton]

Thanks Jeff,

Let me know if you need any specific information / screen shots / logs etc and I'll do my best to provide them.

Andy.

[jclausius]

Andrew:

Let's tackle these as three separate issues, and we can break them into three forum posts, if this post becomes to long.

Issue #1- Unkown files -

The first problem is that some files are repeatedly being set to the "unknown" status. If I get the contents of a project the file statuses are set properly, but if I then close the SOS client and reopen it the same files suddenly revert to "unknown" status and they lose their local version numbers. This appears only to be happening in projects/folders that have an underscore (e.g. "_include") or a full stop (e.g. "ASC.Program") in them (although I can't be sure the problem doesn't happen with other folder names).


When a file is downloaded to disk, the user's local app data directory has a cache of information related to the GET. I'll need to do some more digging around to see if there is an issue regarding periods or underscores, but I am unaware of any problems in that area.

While I'm investigating this problem, do you know if there would be something that would interfere with the data stored on disk. For instance, some people run SOS inside of a VM, and then restore the VM only to find files that are "unknown." This would occur because although the SOS client stored data, it was effectively erased when the VM was rolled back to a snapshot. Or would anything else be interferring with storing data in the user's local app data?

[andrewstanton]

Hi Jeff,

I've since noticed that the Unknown file status is being applied to files/paths other than "underscore" and "dot" file/project names - there appears to be no pattern that I can see in the file/path names affected.

I don't know if this helps (it's probably just another way of seeing the problem) but in addition to seeing the "Unknown" status next to the files in a particular project I can do the following to reproduce the problem:
1. Get Latest (recursive and overwrite) of $/ so that I know I have the latest version of every file in the VSS database.
2. Get Latest (recursive and overwrite) of $/ again, and this time in the Output panel a subset of files from a variety of projects are "got" again, whereas the majority of files are not "got" because they're correctly being evaluated as up-to-date.
3. Get Latest (recursive and prompt-for-action) of $/, and this time a subset of files again from a variety of projects cause a dialog to pop up asking me if I want to overwrite / auto merge /etc, whereas I except no dialogs because every file should be up-to-date due to the previous Get(s).

I'll do some more investigation later and find out if it's the same files being set to Unknown every time. I also note that this problem is affecting files in one particular VSS database far more than any other VSS database I've tried. I don't know whether this is down to the VSS database in question being accessed by more users or something.

Regarding interference to the local disk cache, one of the SOS5 clients is running on a VM but it's only been used once to Get Latest and check out a couple of files (not checked back in yet) (this VM is suspended and resumed sometimes), and none of the other SOS5 clients (the clients where we've noticed the problems) are running on VMs (they are running on native Windows installations on laptops, subject to hibernation/sleep while the SOS5 client is open). All the SOS5 clients are running in Windows accounts that have local admin rights, and I know of no issues/reasons why disk access would be interfered with.

Thanks,
Andy.

[andrewstanton]

I think the following recent post (http://support.sourcegear.com/viewtopic ... 834#p53443) regarding Unknown status and CRCs is describing a symptom of the same problem. I can also confirm the problems I'm experiencing with the Unknown status affect the Visual Studio IDE plugin, i.e. when editing a file in Visual Studio I am sometimes prompted to Overwrite / Auto Merge when I know very well the file has not changed locally or remotely since I last checked it in. Presumably this is due to Unknown status also.

Andy.

[jclausius]

Andrew,

Are you perhaps changing or deleting working folder assignments? Visual Studio is going to instruct the SourceOffSite IDE client to set working folders based on a project, and then GET the files. As mentioned before, when a file is retrieved, a local cache is updated that the file was retrieved on so-and-so date and here is the time stamp of that file.

If a working folder is deleted or reassigned, the local cache for the file retrieval is cleared and if a file exists in the working folder which the GUI/IDE client has no record of downloading, the status is set to missing. For example, if a user (or Visual Studio) assigned a working folder to directory "A", a GET was performed on "A", next the working folder assignment was deleted or changed, and finally the working folder assignment was reassigned back to "A", all files would be "unknown."

[jclausius]

In regards to the CRC post, here is how that works. When a file list is retrieved which can happen on a recursive operation or any "viewing" of a folder which retrieves the file list, the server sends a CRC calculated for each file. Upon receiving the file list, the client will check CRCs of any file of which it cannot identify. If the files are the same, the unknown status would be changed to "blank" as the CRC identified the file.

[andrewstanton]

Hi Jeff,

The files with the Unknown status are not contained in projects that are assigned working folders by the Visual Studio or otherwise. All projects in the VSS database inherit their working folders from the $/ working folder (i.e. there is only one assigned working folder).

I can send you the Output from the VSS client if that helps.. Do you have an mail address I can use to send you these logs?

Thanks,
Andy.

[jclausius]

Please send any logs to support AT sourcegear DOT com. Include a reference to this post.

In regards to working folder assignments, are you saying there are NO projects in this VSS database in which you are using the IDE client with Visual Studio or other IDE enabled tool? The reason I ask is the IDE based client will always assign a working folder upon binding, and you would have one set for the folders containing the solution and project unless it was later deleted.

[jclausius]

Andrew,

We've spent the last two days trying to recreate your problem #2. Unfortunately, we've been unable to recreate the problem. We've tried status search on different statuses (edited, missing, etc.), with and without File List synchronizations. Nothing turns up files which would be "outside" the status search folder (which can be seen on the Status Search dialog as well as the title of the search results). We even tried to mimic the folders from previous screen shots.

Is there a concrete example which may help us track down this issue?

[jclausius]

One last question...

Is SourceOffSite 4 perhaps installed on this same exact machine? The SOS 5 client will try to read that cache file for file lists and tree structures. There have been problems with SOS 4 that the cache is corrupted. It is a wild guess, but if SOS 5 read an incorrect SOS 4 cache file, that might explain some of this behavior as well.

[jclausius]

Andrew,

Another question... about how many FOLDERS are there within the VSS database?

[andrewstanton]

Hi Jeff,

There are 214 folders (projects) in my VSS database.

Thanks,
Andy.

[michaelpitt]

Hi Andy and Jeff,

This sounds like exactly the same behaviour I have seen as pointed out in this post: http://support.sourcegear.com/viewtopic ... 10&t=13170

I have seen the same phantom files. If you do a Refresh File List they disappear.

Cheers,
Michael