Revision Control Vs Version Control

[plasser.us]

We just implemented Vault Professional 2013 in our company couple of months ago. We have been debating whether we need to use Vault Revisions or not.

Vault revisions make more sense for companies that issue drawings based on Revisions. If a drawing is issued at Rev A for a machine#101 this year, same drawing can be issued at Rev B with a change for new machine#102 next year. If they ever build machine#101 Rev A can be issued again.

We don’t work like that; we don’t issue drawings with Historical Revisions. We always issue latest Revisions. If a change has to be made to a drawing that functionality of previous machines we create a new drawing with new number. This way it doesn’t affect legacy data.

Using Vault Revisions is taking lot of our time, if someone accidently changes state of a released file to Work in progress instead of doing quick change there is a Rev Bump and we have to go back and delete file and add it again. There are files with preveious revisions being vaulted for the first time and we have to manually change their revisions. Parents become dirty as we manually change revision for any child and its becomes difficult to release the parent until its checked out and checked back in after capturing the revision for child.

I am leaning towards following two options.

1) No Vault Revisions for all design files, manual revision table in drawings. All design files will be assigned null revision scheme.

2) Vault Revisions and Vault Revision Table only for drawings.

Vault Revisions are new to me. I need feedback from someone who has more experience. I am not sure if using Versions with Lifecycles (file locking) has any downside? The only downside I can think of is getting previous versions.

[mikel_martin]

I think of one of the key reasons for using revisions is more about the historical record than anything else.

Often there are legal implications to what revisions of a part within a specific revision of the assembly.

Using revisions on the models maintains that historical record and makes it easy to retrieve it again when needed.

Here are some ideas that can help. These suggestions wont be applicable to everyone, do what makes most sense for you.

1. Change your lifecycle definition to have the state from Released not bump the revision. Do that later in the process with another state. For example; have a state called Edit, and then another state called Commit Edit. Change the security on Lifecycle so that only select people can go from Edit to Released and everyone else must always go to Commit Edit first. Make the transition from Released to Edit not bump the revision. Make the transition from Edit to Commit Edit bump the revision. Then if you get into a case where you do not want to Commit the change, you can go back to the previous version and have one of the selected people change from Edit back to Released. Hopefully this is not an everyday occurrence and is manageable. The trick to making this work is that you need all new revisions to go to Commit Edit and be checked out and back in one time in order to consume all the new revisions before going to released.
   
   
2. The revise command has a little known feature in the pulldown list which allows you to extract the revision number from a mapped Vault property. If you have existing models with an iProperty that contains the revision, you can map it to some Vault property (call it legacy revision for example). Then use the revise command to create the next revision using the value from that property. This feature was built to handle the case of legacy data.

Hope these help.

[plasser.us]

Thanks for your input. I understand your point regarding maintaning historical data makes complete sence. Attached is our life cycle defination. Quick change is same as edit in your example, WIP is same as commit edit.

What I follow from your suggestion is to get rid of the transition from released to WIP (shown in phantom). Make it mandatory for everyone to go from release to quickchange first (no rev bump) later change state from quick change to WIP if we want commit to change. This way we can avoid accidental rev bumps

I didnt follow this sentence in your post "Change the security on Lifecycle so that only select people can go from Edit to Released and everyone else must always go to Commit Edit first." Why do we want to make it mantdatory for everyone to go to commit edit? Can you please clarify.

It would make more sence if it was "Change security setting on Life cycle so that only select people can go from Released to Commit edit, everyone else must always go to Edit first."