Dangerous 2.0.6 Behavior (source control broken)

MarlonR · Post by **MarlonR** » Wed Apr 13, 2005 11:29 am

I am not sure if this is isolated to our configuration or not. However, this is the behavior that we've experienced:

Via VS.IDE we edit certain projects, an individual's instance of the source integration can break without reporting an error to the end user.

The user simply continues checking in a checking out a file thinking he/she is sending the latest version to the SG server. However, their changes aren't being checked in.

We've found that deleting the project and reloading it from Source Gear seems to resolve the disconnect issue. I say its dangerous because an individual can go a while without knowing if their changes are not being communicated and simply relies on the checkin and checkout icons on their local IDE view, which is misleading.

Is there a configuration setting, patch, or something that will ensure that the VS integration doesn't (without error) disconnect from the source control system?

Marlon Rabara
mrabara@mortgageit.com
Application Architect
MortgageIT, Inc.

dan · Post by **dan** » Wed Apr 13, 2005 12:01 pm

Is the project disconnected from Vault or unbound from source control?

An upgrade to 3.0 might help isolate the problem, since we have the ability to log the calls be made, and also more output to the Output window in Visual Studio when an error happens.

Guest · Post by **Guest** » Wed Apr 13, 2005 4:01 pm

If you view the source control bindings, everything is connected and valid.

I'll have to check with individual that purchased our licenses.

I noticed the existence of an _sgbak. What is the purpose of that folder and does it have something to do with the issue? I was wondering if the algorithm that works with _sgbak could be out of sync and that's why deleting and starting over fixes the disconnect?

I'm just taking wild guesses here.

We are neck deep in a couple of major releases, how smooth is the 3.0 upgrade?

MarlonR · Post by **MarlonR** » Wed Apr 13, 2005 4:11 pm

Sorry, let me also mention that it isn't an entire project that is disconnected. For example:

When I add a file, the file is added to source control. However, the new file won't be added to the project because, althought the project file gets checked out upon adding the new file, the project file doesn't get pushed into Source Gear when we check it back in and the next person getting latest can only see the new file in SG (via the client) but not in the VS.IDE. In this scenario, the project file never communicated back to the SG server on a checkin.

There have also been times when it was another file other than the project file, but it isn't all or nothing.

I haven't heard of any mention of issues from my NY team. The SG server is based in NY and my team (California) is connecting across the country. It works great except for the recent issues...

dan · Post by **dan** » Wed Apr 13, 2005 4:20 pm

It's hard to say much without some log output. The next time it happens, you might check the status as reported by the Vault GUI client, and verify the status of files is Edited and not something else (like Unknown, for example, which will cause problems).

The _sgbak folder is where Vault puts files it overwrites that it can't reproduce (like edited or Unknown files). The presence of that folder indicates something happened to overwrite files previously.

The most painful part of the upgrade is that everyone must do it at the same time (3.0 clients are not compatible with 2.0 servers and vice versa).