FILE REVERT FINDINGS

Revised 4/23/2008 - DRJ

FILE REVERT FINDINGSSummit Valley Equipment & Engineering

Dan Johnson4/23/2009

TABLE OF CONTENTS

SUMMARY

FILES REVERTING TO PREVIOUS VERSIONS

SOFTWARE

USER WORKFLOW

WHAT CAN BE DONE

CONCLUSION

CASE STUDY 1

PROBLEMATIC WORKFLOW

RECOMMENDED WORKFLOW CHANGES

RECOMMENDED SOFTWARE ENHANCEMENT

CASE STUDY 2

PROBLEMATIC WORKFLOW

RECOMMENDED WORKFLOW CHANGES

RECOMMENDED SOFTWARE ENHANCEMENT

SUMMARY

FILES REVERTING TO PREVIOUS VERSION

Around April 3, 2009 it was discovered that, in a few cases, files did not retain the changes that had been made. Users opened files to discover that they were looking at an old version. A few days were lost in re-work in order to change the files again. The possibility of this occurring is obviously of great concern, so an investigation was launched to gain an understanding of what happened in order to prevent future occurrences of the same problem.

SOFTWARE

Upon discovery that a few files had reverted back to a previous state, assumptions were made by the users that the software was the cause. Word got around and there was a panic that the software itself was reverting files back to a previous state on its own. Later testing, along with a study of the timeline and historical versions of the files in question showed that the software was not directly to blame, though it could do more to protect us from this situation.

USER WORKFLOW

The only proven way thus far to reproduce this problem has been a flaw in the user workflow related to answering a user prompt incorrectly. By working around (outside) the Vault for a significant amount of time or not checking in changes but rather keeping them saved locally, users create a situation where the local file is no longer in sync with the last version that was saved in Vault. Later, when they try to open the file from the Vault, they are prompted with the following message: File ____ is checked out to you. Are you sure you want to replace it with the version in the Vault? This prompt is asking the user if they want to overwrite the newer (local) version of the file with the older one in the Vault. If they click Yes or Yes to All they are telling Vault they want to go back to the last one that Vault had seen. This is the most likely scenario of what occurred in the two cases.

Unfortunately, the above workflow never allowed the updated (newer) version to make it to the Vault. Therefore, it is impossible to make Vault go back and activate the newer version.

Early assumptions that one user had overwritten the other users files with an older version were proven to be wrong and could not be reproduced.

WHAT CAN BE DONE

Because we can reproduce this error, we can identify what workflow steps can cause the problem. This allows us to adjust our workflow to prevent the problem from occurring. The simplest prevention is for the users to checking each file in to Vault whenever closing the file. If this is not done and the files are out of sync, users must answer the above prompt correctly.

We can also make recommendations to Autodesk to further protect us from this workflow. If the software allowed the administrator to force a check-in on file close, for example, this particular problematic workflow would not be possible. Enabling the administrator to prevent users from switching to a non-Vault project file (.ipj) in Inventor would also help in preventing similar occurrences of the problem. Vault could also have an option for the user to save the local version to a backup version in the Vault while affirming that they would like the current version to be the latest version from Vault.

CONCLUSION

This document will provide more detail of the workflows and fixes for this issue below. Overall, the benefits of the Vault outweigh the challenges.

The benefits are numerous. It facilitates group collaboration with files (especially 3D Inventor files). It ensures file integrity by ensuring that only one file can have a given file name and that only one user can change a file at a time. It tracks the history of files so that users can easily restore the file in an earlier state (not accidentally, but intentionally). It allows files to be locked down when they have been released so that changes cannot be made without the appropriate revision process. It allows users to work on large 3D files locally (which is much faster than working over a network), but also allows for backup, since the files are checked in to a server. It allows folder level permissions to prevent certain users from accessing protected folders. It enables design-re-use with 3D Inventor files that would otherwise be difficult and cumbersome. It manages the links between files. It allows for users to search for files based on the file name, but more importantly, based on properties or words within the file. It promotes accountability by showing who changed what and when.

The challenge is also big. Vault has a learning curve that is difficult for some users. With the power it provides, there is a degree of complexity for those who have never worked within a database. As we have seen, there is a potential for users to enter into problematic workflows related to managing files that they did not have to consider before.

Overall, the CAD group has come a long way in understanding how to use the Vault and the reasons for it. The level of frustration has dropped off, with the exception of the rare incidents like this one. Most Vault-related emergencies can be quickly solved or reversed with no problem. Vault does prevent many other emergencies from occurring (see above).

The CAD manual will be updated and a meeting will be held regarding this topic. We will discuss how to avoid this problem. As stated earlier, suggestions to Autodesk will also be made to enhance the software and prevent this issue from occurring in the future.

Though this can be a nebulous problem, the users felt that the Copy Design and the Get Entire Folder commands should similarly be investigated to see if a problematic workflow involving those commands is possible. Some additional testing will likely be done in these areas.

The good news is that this problem is not widespread and does seem to be contained to these few instances. Also, this situation seems to be avoidable with some adjustments to workflow. Software enhancements to enforce the proper workflow will also help.

CASE STUDY 1

The following is a reproducible workflow that triggers the file-revert problem. This workflow, or one similar to it, was the most likely cause for one of the two incidents.

PROBLEMATIC WORKFLOW

Day 1

1. Open Inventor and begin working under the Vault project file (.ipj)

2. Create a new part (rectangle)

3. Save

4. Check in

5. Check out

6. Change design of part (to circle)

7. Save

8. Close file without checking it in

Day 2

9. Use open from Vault icon (not the standard open button with a folder icon)

10. Answer Yes to the following dialog: File ____ is checked out to you, are you sure you want to replace it with the version in the Vault?

11. (File opens upas the rectangle checked in during step 4

RECOMMENDED WORKFLOW CHANGES

The problem could have been averted in three different places (shown in red). (Notice that the correct version (the circle) never made it to the Vault.

In step 8If the user checks the file in, the problem is averted. The Vault would have received a copy of the circle design. Not checking in the file upon closing it allows the local file and the last version in Vault to be out-of-sync, thereby creating an opening for the problem. The longer the user procrastinates checking in the file, the more potential work could be lost.

In step 9If the user (being aware that the local copy is newer) uses the standard open (folder icon) instead of the open from Vault icon, Inventor will open up the local version and everything will be fine. Since the open from Vault icon was used, it prompted the dialog in step 10.

In step 10If the user answers No, the problem is averted. Inventor would have opened up the local copy (the circle) which would eventually get checked in.

RECOMMENDED SOFTWARE ENHANCEMENT

There are ways that the software could be enhanced to prevent the above workflow from occurring. The following enhancements (or a variation of them) could help close this loophole.

Allow the administrator (or userbut preferably the administrator) to configure Inventor and AutoCAD to force a file check-in upon closing. This way, the local file and the file in the Vault will be in sync. An alternative would be to either force a check-in or an undo check-out, but under this configuration, the user would not be able to close the file and keep it checked out.

If the user is prompted with one of the following: File ____ is checked out to you. Are you sure you want to replace it with the version in the Vault? or The file is NEWER than the latest one in the Vault, do you want to replace it with the one in the Vault? the problem has a potential to occur. If the user selects Yes, the local (newer) file is overwritten with the (older) one in the Vault. If this occurs, Vault could save the local (newer) file into an old version in the Vault. In other words, the local copy gets saved to the Vault, but not as the latest version. This way, if the user answers incorrectly, they still have the ability to go back and activate the previous version (which is the newer one from the local workstation).

The dialogs discussed above could have bitmap pictures of the two versions (hopefully) showing the visual difference between the two (the local and the Vault versions). This could help the user answer this prompt more accurately.

CASE STUDY 2

The following is also a reproducible workflow that triggers the file-revert problem. Because of a broader timeline (i.e. 6 months), it was more difficult to recall the workflow that was used. However, this workflow or a variation of it is highly likely.

PROBLEMATIC WORKFLOW

July 2008

1. Open Inventor and begin working under a non-Vault project file (.ipj)

2. Create a new part (rectangle)

3. Save

4. Close file without checking it in

5. Use Autoloader to check the file into Vault.

Time passes

6. Open the file from its original non-Vault location

7. Change design of part (to circle)

8. Save

9. Save drawing to AutoCAD .dwg format (capturing it as a circle)

10. Close file

April 2009

11. Now working under the Vault project file (.ipj)

12. Using Windows Explorer, move the files under the root directory for the Vault project

13. Open the file from the standard open button (i.e. folder icon)

14. Check out (with Get Latest Version from Vault option checked) the latest version in Vault was the one that was auto-loaded in step 5 (the rectangle). The circle design from step 8 is over-written.

RECOMMENDED WORKFLOW CHANGES

This problem was likely facilitated by keeping these particular files outside of Vault after the implementation of Vault was in place. Keeping one foot in the Vault and one foot out can lead to the files being out-of-sync once the time comes to put them back in Vault. Though harder to track the cause, this case will not likely reoccur because the vast majority of files are being created and maintained within the Vault project file (.ipj).

In step 1If the user works within the scope of the Vault project, the problem would have been averted. (This was not possible in this case, because this model was created before the Vault implementation was in place).

In step 4The file wasnt checked in because the non-Vault file was active and it couldnt be checked in. (Autoloader was used to check the file in later.)

In step 6After the file had been loaded into Vault in step 5, it should have been checked out and worked on under the scope of the Vault project file. Instead, the design was modified in the original non-Vault location, making the file in the Vault out-of-sync with the one that was being changed.

In step 12Using Windows Explorer to move files in this case would be okay, but this can be problematic to the directories that Vault is expecting.

In step 14In the Check Out dialog, the user should have unchecked the Get Latest Version from Vault option, which would have checked the file out while maintaining the correct design (the circle).

In general, switching back and forth from a non-Vault project file (.ipj) and a Vault project file can present potential problems. Users should always work under the Vault project file.

RECOMMENDED SOFTWARE ENHANCEMENT

There are ways that the software could be enhanced to prevent the above workflow from occurring. The following enhancements (or a variation of them) could help close this loophole.

The administrator should be able to configure Inventor to stay within the Vault project file (unless a password is used, etc.)

Inventor crashes occasionally create a temporary Inventor project file (.ipj) in the C:\Temp directory. This can cause problems for the unsuspecting user who doesnt think to switch back to the Vault project file.

If the user was working outside of the designated Vault project file, a strong alert should show up on the user interface, making them aware of the circumstances.

The dangerous nature of the two dialogs discussed in Case Study 1 and 2 should be emphasized to a greater degree than a generic dialog with basic text (i.e. Exclamation icon instead of question icon, etc). A warning should be part of this dialog so that the user is aware that he or she could potentially be overwriting the local file which has never been checked into Vault and will be lost.

8