Renegade Status and Merge Fails

[rtinker]

Been using SOS since the 4.x days. One developer where the server is located uses VSS. Started using Visual Studio 2010 (not sure if that has anything to do with it) but lately have been getting a lot of "Merge Failed" when we check-in from Visual Studio, and then in the SOS client when I do a get latest it appears to work fine but the status of several of the files is Renegade, even though the version numbers match and when I tell it to show me the differences, there are none.

Upgraded both the client and the server to the latest version, client is 5.0.3, and get the same results. (Upgrade of the server wiped out the settings too!)

Help!
Thanks

[lbauer]

Are both you and the VSS user modifying files in the same VS 2010 project?

Are you saying you have a Renegade status even after doing a Get Latest?

[rtinker]

Yes to both questions ma'am!

I discovered that for some reason, SOS is not marking the files as read-only, or something in its internal status is messed up.

I created a VPN connection and used VSS, pointing the working folder to the same directory as what SOS was set up to use. When I do a get latest there, it found the files marked read-write, so it did a merge and checked out the files. I then checked them back in (still in VSS), but when I switched back to SOS, it still showed a renegade status.

Thanks

[lbauer]

Check your file options for SourceOffSite in the client under Options -> Files -> File Settings. Make sure the checkbox for "Use Read Only Flag for Files That Are Not Checked out" is checked.

It's possible your files are renegade because you used a VSS client to merge and make changes to files in the SOS working directory.

SourceOffSite keeps the client-side cache with date a file is retrieved. If the date of the file in the working directory is different than the date in the cache, SourceOffSite considers the file to be modified.

If a VSS client modifies files in the SOS Client working directory, it doesn't update the cache, so SOS will think the files are different. A renegade file is one that is modified but not checked out.

Another issues is that SOS Client tries not to overwrite modified files (renegade or edited) in the working directory. The default on a GET or Checkout is to not overwrite, but attempt automatic merge. This option can be changed in the GET/Checkout dialog or in SOS options.

In Visual Studio, this option is in Tools->Options->Source Control->Plugin Settings->Advanced->Files

[rtinker]

The files in the working directory were never changed with VSS until I just set it up yesterday to see if VSS was having issues. The problem existed prior to that when VSS was never used to modify any files in the working directory. It was always SOS client or SOS via Visual Studio 10.

The files setting has always been set to use the read-only flag.
The setting for setting the date on files was check-in, but I just changed it to "current", so I will try again to see if that changes anything.
The option for files modified was to attempt automatic merge, and that is part of the problem - via Visual Studio it always reported that the files could NOT be automatically merged, so that caused me to use SOS client which while it does not report a merge problem, it also did not reset the status and many of the files still show renegade.

Is there a procedure to reset the cache? Perhaps there is an abundance of cache-crud or something happened to it and it just needs to be reset/rebuilt?

[lbauer]

In Vault 5.0, the client-side cache is in your user profile, under Local Settings\SourceGear\

The client-side cache is called DBx.SOS and is located in C:\Documents and settings\<username>\Local Settings\Application Data\SourceGear\SourceOffSite\Servers\<servername>

Or in Windows 7, it's under Users\<username>\AppData\Local\Sourcegear.

I'd recommend backing up or checking in any modified files, closing the SOS Client and Visual Studio, then deleting the cache. You could also unbind and rebind the project to make sure your working directories are set properly.

Let me know if this does not resolve the problem.

If not, I'd suggest we schedule a remote assist session where I can take a closer look. Email support at sourcegear.com, Attn: Linda. Please include a link to this forum post.