thomas_woelfer

hi.

i have a vss 2005 setup (integrated into vs 2005) with 4 machines on two sites. the sites are connected via vpn. we're using the normal connector (not the http one). we're working on a solution with ~50 projects.

we quite often find that doing a "get latest version", does not, in fact, get the latest version of the solution. sometimes only a single file is omitted, sometimes complete projects are not updated.

this obviously leads to failed builds, which is when we notice that GLV didn't work. doing another GLV at this point most of the time does resolve the problem, however, vss inconsistency in getting the latest version of a source file (or complete project) is not exactly helpful.

any ideas what would be causing this

WM_THX
-thomas woelfer



Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

Brad Peterson

Thomas,

I have some questions for you to help us narrow down the problem:

1) Are you running the LAN service on the server (Check the LAN tab from the Server menu in the Admin program)

2) When you encounter the issue for the solution (one or more files is not gotten) - can you reproduce the probem by selecting the file itself and attempting a get

3) The Get dialog, which equivalent to Get Latest Version, brings up a dialog that displays file status (whether they are out of date) - Does it show the files that are not being pulled down as being the same as the server version

4) Are you mixing direct Visual SourceSafe commands with commands from inside of Visual Studio

You may want to check the project cache timeout values in the SRCSAFE.INI files on the client machines that are pulling data down - if the data was just checked into the server, it may be waiting to update the server information and not detecting the newer files until the cache is refreshed.

Any information you could provide would be helpful!

Thanks,

-Brad Peterson

Visual Studio Editor/Source Control Integration Test Lead





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

thomas_woelfer

Brad,

> 1: yes, the lan service is running on the server

> 2: no, this doesn't repro very good. most of the times, a second get while actually get the file. sometimes i won't.

>3: i don't know. i will check this, the next time a get fails.

>4: nope. apart from running analyze once a week, we're only using the integrated stuff from visual studio.

>5: um - there is no srcsafe.ini file on the client machines. should there be one where

WM_THX
-thomas woelfer





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

Brad Peterson

Thomas,

My bad - the SRCSAFE.INI file is located in the directory that your database lives in:

In the file, look for:

PrjEntryTimeout ¨C how soon will a cached folder information be refreshed and new children discovered, default 10 seconds
StatusTimeout ¨C how soon the status of the files is refreshed, default 5 seconds.

If for some reason, the PrjEntryTimeout is set to a high value, try adjusting it down.

Also, for kicks, try disabling the LAN Service and see if you continue to see the issue.

If this keeps happening, could you grab the vssver2.scc file (hidden) or the vssver.scc file from the clientĄ¯s folder and send it it us - we may be able to determine what is happening by examining the file.

Thanks!

Brad





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

thomas_woelfer

Brad,

there's no PrjEntryTimeout or StatusTimeout in my srcsafe.ini.

the problem also turns up incase the lan service is not used. ( i know because we already tried this some time ago. )

vssver2.scc seems to be a binary file. i assume it won't help much if i post the binary contents here - where do you want me to send it to

WM_THX
-thomas woelfer





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

Brad Peterson

Thomas,

Send the binary to me at bradpe@microsoft.com - We will take a look at at on our end.

-Brad





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

Brad Peterson

Thomas,

Got your file.

We will take a look at it.

I am going to close this this thread and follow up with you outside of the forums.





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

thomas_woelfer

sorry to say so, but its been ten days now, and i haven't heard anything from you guys. whats up with that "follow up"

WM_QUERY
-thomas woelfer

(to be collected: SpamTrap@woelfer.com )





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

Rhys666

If you do get any follow up information would it be possible to share it as I and a number of others I'm working with are experiencing growing pain with this issue. It's been happening to us for a while now but is starting to really get up my nose now. Thanks very much.

Rhys





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

thomas_woelfer

i will share it here - but i haven't heard anything as of yet.

WM_FYI
-thomas woelfer
http://www.die.de/blog





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

Alin Constantin - MSFT

Thomas, unfortunately there are a lot of things that can go wrong in a GetLatestVersion, and the scci devs will need more information to identify the culprit.

While in VS2005+VSS6 the GetLatest command only translates to a SccGet() call into the scc provider, for VS2005+VSS2005 get latest command is executed a lot differently:

1) for the current selection in SolutionExplorer, all the controllable files in the project are accumulated.

2) and VS calls the scc provider on SccEnumChangedFiles for the files that still appear under scc.

3) the scc provider reads the content of the vssver2.scc file and extract the local version number, CRC and timestamp of the local file (*** incorrect data in the vssver2.scc may be a problem)

4) the scc provider tries then to see which is the latest version on server.

4.a) If the LAN Booster service is used, the client machine does an RPC call to the server hosting the database, and the server is going to access the database, and return to the client the latest version number, CRC and timestamp (*** here the server might be influenced by timeout/caching and return old data).

4.b) If the LAN Booster service is not used, the client machine tries to get directly the data by accessing the database over UNC share (*** again caching and timeouts may be problem)

5) once it has the data for both local file and the server file, the data is compared and SccEnumChangedFiles returns some flags for the file that require updating (*** at some point we had a bug here that we detected a file changed, but the list of flags were returned in a different order than initial files, so even though SccGet was performed in next step, we did the real get for the wrong file - we fixed this before RTM)

6) VisualStudio will call the provider on the real SccGet command ONLY for the files that require updating.

7) The provider in the SccGet will do again the version checks (this time the client accessing directly the database over UNC) plus a lot more other checks (e.g. verifying right permissions on parent folders, etc), and the latest version is got if necessary.

8) if one of the project files or solution have changed, they are reloaded in VS

9) during reload of a solution, we detect if there are any projects that you don't have locally and we do another SccGet for them. Similarly, if there are new files listed in a project that you don't have locally, we do another SccGet for them (*** so, if 2 users checkout a project, add files with the same names, one checks in and the other one does a Get, the new file will not be updated at this step - this is by design!)

Pretty much, anything can go wrong at any of these steps.

Here is what I'd try to reduce the posibilities:

- when the GetLatest problem happens, open the Get... dialog for the same selection in SolutionExplorer, don't click the Get button, just look at the files listed there and what VS thinks it should do for those files. (this should tell if we do a wrong detection of changed files; if we do the incorrect detection, Brad should help you look into vssver2.scc files and see whether local data/server data is stale or perhaps there is a code bug in the comparison algorithm)

- when the GetLatest problem happens, do it again for the same selection in SolutionExplorer. Does it still repro the second time, or did it got more files now If more files were got, were those files in the project before the GetLatest, and were they checked in If it still repro, wait 1-3 minutes then do the GetLatest again for the same selection. Does it still repro (e.g. this should tell whether it's a cache timeout problem)

- does this problem happen when the LAN booster service is not used (to eliminate differences between what the client reads from the database and what the server reads from the database)

- is there anything particular about the files that were not get What types of files are not get What was the selection in SolutionExplorer when you did the GetLatest E.g. we had users complain about "no get" in step 9 for newly added files or projects, but that is by design (a second Get command should retrieve the files in this case). Selection may also influence a "no get" in step 1 - for instance if you select and do a Get for an asmx file that has a newer code behind file only in the database, the code behind file will not be retrieved - again by design (without doing a GetLatest on the project node we have no way of reloading the project file and discovering there are new files in the database in this project)

Alin





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

thomas_woelfer

Alin,

>> when the GetLatest problem happens, open the Get... dialog for the same selection in SolutionExplorer, don't click the Get button, just look at the files listed there and what VS thinks it should do for those files. (this should tell if we do a wrong detection of changed files; if we do the incorrect detection, Brad should help you look into vssver2.scc files and see whether local data/server data is stale or perhaps there is a code bug in the comparison algorithm)

i will try to do so, and post my findings in this thread - ok

>> when the GetLatest problem happens, do it again for the same selection in SolutionExplorer. Does it still repro the second time, or did it got more files now If more files were got, were those files in the project before the GetLatest, and were they checked in If it still repro, wait 1-3 minutes then do the GetLatest again for the same selection. Does it still repro (e.g. this should tell whether it's a cache timeout problem)

normally, what happens is this: someone does a GLV and tries to build. the build fails. thus, the person does another GLV and tries to build. most of the time, it now works. iow: waiting, and doing another GLV helps. I have no data about that, but i'm pretty sure that all files have been in the project (and checked in) at the time of the first GLV.

>> - does this problem happen when the LAN booster service is not used (to eliminate differences between what the client reads from the database and what the server reads from the database)

It does happen when the LAN booster service is not used. (We tried that for some time.)

>> - is there anything particular about the files that were not get What types of files are not get

c# source code files; maybe resource files, but incorrect resource files don't break the build, so nobody notices emmediately.

>> What was the selection in SolutionExplorer when you did the GetLatest

we right-click on the top-level Node "Solution" and select "Get lastest version". i guess that means "get everything for that solution"

>> E.g. we had users complain about "no get" in step 9 for newly added files or projects, but that is by design (a second Get command should retrieve the files in this case). Selection may also influence a "no get" in step 1 - for instance if you select and do a Get for an asmx file that has a newer code behind file o

i don't think this is the case here. its simply not getting a file that has been in the project for ages, that is checked in, and that has been changed recently.

WM_THX
-thomas





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

thomas_woelfer

Alin,

i've just sent this info to brad via email.

WM_FYI
-thomas woelfer
http://www.die.de/blog





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

thomas_woelfer

Alin, Brad -

is anyone looking into this

WM_QUERY
-thomas woelfer
http://www.die.de/blog





Re: Visual Studio Source Control and SourceSafe Get latest version not reliable

Alin Constantin - MSFT

Not me, sorry, I don't work in VSS anymore and my time for VSS support is limited or none. Imho Brad should contact Richard or someone else providing VSS support now and work with you directly to try getting a repro...

Alin