Vault 4.1: Rename and Check-In cause inconsistent DB

[avonwyss]

I just had a very strange and somewhat frightening experience in Vault (Client 4.1.4, Server 4.1.3). I had created a file and checked in it one time. Then, using the VS.NET Enhanced Client, I edited and renamed the file multiple times without intermediate check-in (both editing and renaming). Somehow, suddenly Vault told me that the file had been checked out to another location, which wasn't true. The Vault client told me the same thing. So I did an Undo Checkout on the server, and checked the file back out which seemed to work. Then I committed all the changes to the repository.

And this is where the repository became "half-baked", against your promise:

Atomic Checkins
You can checkin a group of logically-related operations as a changeset, and the checkin operation is atomic. The entire changeset either succeeds or fails. Your repository is never left in a half-baked state.

The new file name was shown in the Vault client, but with remote version 1 and remote size 0kb. Checkout succeeded, but the client then still showed the dialog as if the file had not been checked out, and pretended that it was checked out on another location (which it wasn't). Undoing the check-out via server interface worked, but the same behavior persisted. The new file name was in none of the histories (folder history by item, changeset details etc.). My changes had apparently not being persisted to the server, even though the transaction was not aborted.

I tried to return to a working state by renaming the file back to the old name (commit), renaming it back to the new name (commit), checking it out (no overwrite) and checking it back in. This worked to get the changes into the repository, but an automatic check-out on edit in VS.NET now shows the file as not being controlled by Vault, still the menu offers the "check-in" but doing so returns the message that there are no files to be checked in - which is consistent with the pending changeset which does not include this file. The normal Vault client now shows the file as renegade (no change after Refresh).

That this inconsistency could happen is very, very disappointing and does break your promise of the "reliable" and "atomic" system which will "never [be] left in a half-baked state"!

How can I return to a really working state and make sure that the server will not choke on this, especially on migrations to newer versions (V5 for instance)? I will try and clear out my client-side cache in order to reset any wrong information on the client, but I'm afraid that there is still something wrong on the server.

I have a backup copy of the inconsistent DB, but as you'll understand, I cannot send it to you, but I am willing to assist to some extend if you need more information on what happened. However, I have attached a screenshot of the history after the fix which doesn't disclose too much information but shows the issue:

Folder History with inconsistent rename

VaultInconsistency.png (180.71 KiB) Viewed 1704 times

Note the following:
The file in question is ValueStyle.cs. It was created near the bottom of the history. Up to the rename operations on the top, the file was never checked in or renamed (none begins with V... and the two St... are not StyleDefinition.cs). Still, the rename shows itself as name.

[lbauer]

We certainly want to look into this. Email support at sourcegear.com, Attn: Linda. Please include a link to this forum post and include your phone number.