In workgroup PDM, I set primary (letters) and secondary (numbers from 01 to 99)) revisions
The primary revision is only changed when the file is changed to "released" in lifecycle status
The secondary revision is changed for each checkin
In new PDM standard, I'm only allowed to set the primary revision and the secondary rev. (numbers) seems to be setup by the program itself
Am I correct here?
Thank you
Is there some kind of checking file in with no revision change as "working copy" in workgroup PDM?
Not exactly......it always creates a new version which you can return to if you want. If I remember correctly, the working copy overwrites the last version in the vault...ePDM doesn't do that.
We tried to minimize the size of the Vault (workgroup) and the engineers here keep working on the "working copy" as long as they feel necessary
creating a new version for each check-in (ePDM) seems to increase the size of the Vault for many little changes (at least once a day to make sure files are safe for backup from the company server)
You can set up Cold Storage to delete or backup older version if disk space is a concern.
Jason,
It's the way I did with wPDM - archive all the old rev.
What happened is - I don't do it on a daily basis - just monitor the Vault size once a while and go thru all the files and archive them - it's time consuming so I asked engineers here keep the "working copy" as long as they need before bump up to a new rev
We did not find file size growth (archive server "physical files") to be much of a problem.
Re: reducing file size on your server.
Re: File size when adding revisions on a model in (E)PDM
We encouraged users to check in everything by the end of the day, and definitely before the weekend. I'm sure there are some other posts on this too, I thought I recorded how much our vault grew in a year...
I increased Cold Storage versions up to over 100. Deleted Versions after that, kept Revisions.
Not exaclty....and it depends on what you want to show on your drawings. The version number is sequential and built into the system, each check-in creates a new version however this is not written to the data card and thus would not be shown in your title blocks.
Multiple revision schemes can be setup. For example our release revisions are letters only (A,B,C, etc). But during development or engineering change it's a letter.number (A.01, D.05, etc). These schema are assigned to a state (Release, Inwork). Then the transition action going to that state is set to %nextrevision% for the revision field on the data card. For 'Release' we also use the 'Increment Revision' action to put the label on it in the history.