Check-out in VS Enhanced Client doesn't always get latest?

[Mike Dimmick]

There have been persistent mumblings among my team-mates about problems with Vault for a while. I just observed a situation where it appeared that one of them had used Get Latest, then Check Out, and edited the file (extensively), only to discover that the file contents weren't actually the latest. Checking the standalone client, I could see that Vault thought the most recent version in the repository was his current baseline, but changes in that version didn't appear in the actual working file.

On previous occasions some have reported problems where, when Get Latest has been used on a project, their changes in some files that were checked out were lost.

Has anyone seen anything like this before? To be honest, they both sound like user error - in the first case, already having edited the file and setting Do not overwrite/merge later in the Check Out dialog; in the second, setting Overwrite. Still, it's possible that VS didn't reload the file.

Unfortunately there's nothing useful in the server log. Client logging is off, server log is set to 'Quiet'.

We're writing a C# smart device (Windows Mobile 5.0) application in Visual Studio 2005, using Vault 4.1.1's Enhanced Client. Everyone else is using 'VSS Mode' - I'm ploughing a lonely furrow with 'CVS Mode' (and I've not had any issues). We're all using VS2005 SP1 on XP SP2 except for the user on Windows Vista who has SP1 plus the Vista update.

The system is very lightly loaded - 8 users total, repository size 874MB (1.71GB on disk). We use the same repository for all projects and are up to 16,910 versions. This has been upgraded from 2.0.6 to 3.1.8 and now 4.1.1. Vault runs on the same box as SQL Server 2000 (a named instance of SQL Server 2005 is also installed). Server spec is 1 x Xeon 5148 with 4GB RAM, two RAID 1 arrays of 465GB, although there's only 2.42GB free on C: (one array is partitioned into a 12GB and 453GB partition). Disks are connected via Serial Attached SCSI, so there should be more than enough grunt for this workload. Both instances of SQL Server are capped at 1.5GB each.

[ian_sg]

There was a bug fix made in 4.1.1 that applies here. Prior to 4.1.1, there were scenarios where Visual Studio wouldn't reload the file or the user would be prompted to reload and selecting "No" could cause the behavior you describe.

This was fixed in 4.1.1 (and the latest is 4.1.2). If everybody's already running 4.1.1 or later, I would suspect user error as you described.

[Mike Dimmick]

We're all running 4.1.1 but I might see if I can get an update to 4.1.2 scheduled. Otherwise I'll just have to keep an eye on it. I tried various different approaches - checking out when the file has unsaved changes, in VSS mode, in CVS mode, checking out when the file isn't in the foreground, and couldn't reproduce it.

[ian_sg]

Thanks for the update.

[ThomasH]

Hello,

we encounter the same problem in our team of 20 developers. We are using VS 2008 with the enhanced client and Vault Version 4.1.1(18060). In the options of vault the detection of modified files is in default mode, using the modification time. We made some tests with different time on different clients and server, but didn't find any failures. Switching to CRC might help, but isn't really a solution because of our big source tree. It's too time consuming...

Any hints to look for would be great.

Thomas

[moe]

We are using 4.1.2 and have been having the same problems.

We don't really know when this happens as we have only noticed it happen a few times.

I would make some changes and check them in (is viewable in history) basically after someone else makes changes (without getting latest) my changes would be lost (Diff shows my changes as being deleted by the latter checkin)

What could be causing this?

Thanks

[ian_sg]

Are all developers using strictly VSS mode (require checkouts, always request exclusive locks? If not, it's possible to get into a "Needs Merge" scenario. If the merge is not performed, and the warning when resolving the merge status is ignored, it's possible to check-in a change that overwrites a previous checkin.

[ThomasH]

Yes, all developers use VSS mode, always exclusive checkout.

Yesterday we had the problem again with a .rc-File and there we can reproduce it:

One is opening in VS 2008 a resource file with the resource editor, which is checkout by someone else. The latter one makes changes and checks the file in. Now the first one starts making changes too on the already opend rc-File with the editor. He gets no message and no new fileversion from vault. He can make his changes and check them in. Then the former made changes are lost, but noticed in the history.

What goes wrong?

[ian_sg]

This shouldn't be possible.

If you can reproduce the problem, I'd like to see the Visual Studio enhanced client logs, in particular for the second user who's editing when another user has the file checked out.

Information about turning on the log and finding the file can be found here. Follow the directions for the Visual Studio Enhanced Client (the third bullet). You can post the log here or email it to me: ian at sourcegear dot com.

[ThomasH]

Hello Ian

I'll send two log-Files to your personal E-Mail monitoring two issues:

1. Editing rc-files as mentioned in my post yesterday
2. Open a source-file in the editor, which is out-of-date. Type return in the editor(just to checkout the file) and then activate the undo-button once. Then you will see that the GetlatestVersion-operation is undone, which was not a named action for undo before and all the changes from the newer version are lost. Is this a bug of VS 2008 or of the Vaultclient? Why is there a undo-step for checkout (with getlatest)? This should be "Undo checkout" of the vault client...

[ian_sg]

I was able to reproduce the checkout issue you described. It's limited to the resource editor: modifying an RC file in the text editor doesn't have this problem. The resource editor has some odd behavior we need to investigate. We'll have a fix in the next maintenance release: 4.1.4.
(Bug 13772)

I believe the second issue you reported is also worthy of a change. We can't put source control actions on the undo stack, so we can't undo the checkout when you press undo, but we can prevent the get latest from being undone. (The get latest itself is not really undone, which is the root of the problem. The changes in the text editor alone are undone, which makes it appear to Vault that you've made that change yourself.) A fix for this will also be in the next maintenance release.
(Bug 13770)

[ThomasH]

thank you for the quick response. we are then waiting for 4.1.4 cause both issues are very very dangerous. if you can't trust the sourcecontrol system you can't trust your own software development.

[ian_sg]

The undo issue is a trivial fix and will most certainly be included in the next release.

The resource editor is much worse, and I'm going to have to backpedal on my claim that 4.1.4 will include an outright fix. The issue here is that the editor itself is buggy: it doesn't recognize that the underlying files have been modified and it ignores explicit requests to reload. There doesn't appear to be much that we, as a version control package in Visual Studio, can do to fix this. To confirm that, we tested the same scenario with both the VSS 2005 MSSCCI client and the TFS 2008 client (with Get Latest on Checkout turned on). Neither of them handle this scenario well. TFS 2008 has exactly the same behavior as Vault. VSS 2005 does slightly better: it warns you before leaving you in the same bad position.

We'll try to mitigate the problem with a warning, similar to what VSS 2005 does, for 4.1.4. Unfortunately a true fix falls to the Visual Studio team at Microsoft. I can confirm that Visual Studio 2005 also exhibits this behavior, so it's an old bug.

Sorry for the inconvenience.

[neil.gallagher]

Sorry to jump onto this post but we have been having the same issue mostly with .sql files in vs2005 and Vault 4.1.3 with Enhanced Client). Was this likely to habe been fixed in 4.1.4 as well.

Cheers

Neil

[lbauer]

You certainly could upgrade to 4.1.4 (it's free if you're using 4.1.3), to see if the behavior is different, and before we troubleshoot this, it would be best if you were on the latest release.

Is this reproducible? What steps reproduce it?