I've run into a minor issue with Vault 3.0.2 and I'm wondering if this has been found and fixed in later releases.
An employee had checked out a Word document and edited it. The Vault status showed the file as edited, however when she attempted to check it in, the changes were lost, the local file reverted to the version in the database and the change set comments showed that instead of checking the file in, Vault was undoing the checkout.
A closer inspection of her working folder showed that instead of browsing for the path, she had typed it in and mistakenly used forward slashes instead of backslashes (i.e. C:/test folder instead of C:\test folder). When I corrected this, the problem went away. I was able to recreate this problem on my computer.
Has there been a fix in later releases to prevent users from typing invalid working folder paths? I know if you type in a folder that doesn't exist, an message will appear indicating the folder does not exist, however this doesn't seem to be the case if forward slashes are used in a valid path. I also noticed on the same employee's computer that one of her working folders was set to a pdf file (i.e. C:/test folder/test.pdf) and another of her working folders had two forward slashes after the drive letter (i.e. C://test folder). We are considering upgrading in the very near future, but would like to know if any error handling has been added to account for invalid working folder paths.
Strange Vault behavior
Moderator: SourceGear
It would be helpful if the warning was displayed, but more important is the fact that part of the application interprets the path info correctly and another part does not. In this case, we only lost a few changes to a word document. Had we been checking in a days code changes, however, the impact would have been much more painful.
Vault, even though it knew where the file was located and that it had been modified, performed an "undo checkout" rather than a checkin and, without warning, replaced the local copy with the last one in the database.
It's really this issue that we're hoping has been resolved.
I'll admit, I was skeptical at first, but we can repeat the issue at will. If you'd like, we can provide you with the steps necessary.
Vault, even though it knew where the file was located and that it had been modified, performed an "undo checkout" rather than a checkin and, without warning, replaced the local copy with the last one in the database.
It's really this issue that we're hoping has been resolved.
I'll admit, I was skeptical at first, but we can repeat the issue at will. If you'd like, we can provide you with the steps necessary.
Steps to reproduce:
Create a folder on C: called "test folder"
Add a word document to C:\test folder
Create a new folder in Vault
In the Set Working Folder dialog box for the new Vault folder, enter "C:/test folder" and click OK.
Add the word document to the Vault folder
Check out the word document.
Edit the word document and save the changes.
Check in the word document. Instead of checking in the modified file, Vault will undo the checkout and the changes to the local file will be lost.
Create a folder on C: called "test folder"
Add a word document to C:\test folder
Create a new folder in Vault
In the Set Working Folder dialog box for the new Vault folder, enter "C:/test folder" and click OK.
Add the word document to the Vault folder
Check out the word document.
Edit the word document and save the changes.
Check in the word document. Instead of checking in the modified file, Vault will undo the checkout and the changes to the local file will be lost.