I don't want newly created part to have revision when check-in into vault.
Is it possible? or Is it standard format that all checked-in files should have revision?
You can check it in as a 'working' revision. While it, technically, is getting a revision, it's not a released version.
Thank you for your response.
Actually, I don't want any revision, if part is checking-in for the first time and released.
Is this impractical?
Do you mean you want the revision to start at the base un-revised value (IE: -- or 00, A, etc) and stay at this value until a modification is made after release?
Actually I was thinking not to have any revision for a first release. But using -00 revision for the first release is also not a bad idea. But I don't want to use any letters for the first release.
is it impractical not to have any revision for a first release?
In your Vault Admin Tool, under revision scheme, have your 'Primary' be set to listing and have the first one be --. From there, you can use alpha, numerical or whatever else you choose. I believe, anyway, that you can start with --.
I've just tested the "--" method and it reported that it will not accept "--", was looking for an integer value >=0
EDIT 8/4/2014: Misread that. You can put them into the list. Two things about that though:
1. Not sure if there is a better way than completely going through the rev list until whatever limit the business decides on. Setting initial to 0 and working up, it can be loaded automatically and the user (admin) will not have to input the revision schema.
2. The revision schema, using the list, can be set to skip O and L, etc.
3. Not sure how the "Primary value" works with the list, if it acts as Primary value used initially and then goes up to "1" (see below) or if it starts at 1.
Is the EPDM or WPDM? WPDM's interface looks different on my computer.
That is EPDM. My apologies, must have mixed that up somewhere.
In that case, you might want to move this thread to the Enterprise PDM forum. You'll get better answers there.
I was not the original poster, I was posting in response to a question posed, I was in the wrong section.
Whoops, my bad!
Reeshi, your question could be answered a couple of ways, can you tell us the "why" you don't want a revision in a system that is intended to do "revision" control?
You can create a revision for first check in that only means something to your group using PDMW? I create a revision called "DEV" as a placeholder so if someone wanted to get a file into the vault for control or to share. This is not a real revision to us and you could create a revision called "INITIAL" or whatever you want. The software will call it a revision, but if you know it as just a starter check in file or something like that, where everyone understands what it is doing you should be good.
As for it just going in "revisionless" that can't be done, the closest you could do is what Jeff was explaining being starting right off as a working copy, this would show up in the history, but once it moves onto the next logical revision, you would not be able to retrieve it.
Reeshi, it's a matter of semantics, really. WPDM is a storage and versioning system. Whether you have an attribute called revision that you want displayed, the intent of WPDM is to maintain a history not just of individual files, but of full document trees so that you can effectively access an entire project at a particular point in time. To do this, every file checked into the vault has to be enumerated with a version number. Even if a file is checked-in once and never touched again, it has to have a version number. It's like when you go to the DMV and you're the only one there and you still have to take a number and wait to be called. it sounds bureaucratic, but it's neccesary.
Because WPDM only supports one workflow, the overhead and rules are the same for all files. So the lifecycle, primary, secondary, view restricted super-critical, ECO driven workflow for a top-down assembly applies to a dummy part that serves as a placeholder in the BOM for glue.
Having said that, you do have a couple of options:
The first is to use a Standard library for parts you don't want to carry the overhead of revisions. In the Vault Admin tool, on the Standard Libraries tab, you can add locations on your network or workstation-as well as toolbox parts, that are considered not-revision-controlled and they won't be checked into the vault or be subjected to any of the requirements of the vault.
I don't like standard libraries because the files aren't checked into the vault, which means they have to be stored on the network in a read-only folder that only the system admin can get to. I used standard libraries in a shop with 10 cad operators and it was a disaster for performance, stability and keeping files up to date.
If you're willing to do some extra work for the cases where you don't want the revisions and you can live with an initial '00' or something:In the Vault Admin: Vault Settings tab, check the box that says, "Allow latest revision overwrite."
When you check in a document, this will allow you to set its revision to, "read from file," before proceeding
Doing that overwrites the existing vault file without creating a backup version-effectively replacing it as if it had been in its current form all along.
I do this to keep from large files with minor changes from taking a lot of extra disk space. It could just as easily be used to prevent a file from updating revision data.
Another thing you might look at doing is uncoupling your revision table and attributes from WPDM's version attribute.Basically, my revision block and attributes are updated by the user when they right-click on the rev table and do, "Add new revision." When I check-in files, I'll note new ECO's and bump the primary revision as needed. This solution sometimes offends the desire to wire everything up to full automation but there's really very little extra work involved.
Finally, EPDM and Meridian-and probably SmarTeam and Teamcenter all have customizable workflows for different document types and lifecycle states. So if WPDM won't stretch over your business practices, then you should consider upgrading to a more capable system.
Retrieving data ...