Add single file to a configuration; simple steps?

Question

we're creating configurations to spec what a release is comprised of.
We need to add a single file to a configuration. Oddly we've been guessing about and can't figure this out.
I'm creating a configuration from a PWA, stripping out all but one file. Then creating a new configuration from another configuration
(the previous config for this release), then Add member, to add this config. that
has the single file.
There has to be simplier steps?
BTW, the help within RON and the OTN tutorials don't mention this feature on configurations.
Thanks
curt

Answer 1

Here's a work around for adding one or more files to a configuration that works for us.
Forwarned that this is the long way around but at least it's simple in concept.
Back ground:
- one uses configurations to control specific versions of files that describes a release
- In theory release 1.4 should be based on configuratoin for 1.3 plus or minus files and versions of existing files.
- My view is that if you break the verifiable inheritance of the next version from the previous
you are taking a risk.
Meaning, that the next version should always be based on the configuration of
the previous release.
- This procedure breaks the rule the above rule. ;-(
The work around that I've been able to get to work:
Short description: create the next cfg from LATEST, then use command line tool (compare cfgprevrelease cfgBasedOnLatest)
to determine what file versions need to be rolled back to be equal to the previous version, this captures the new files in the latest branch.
steps:
- Refresh your PWA to get the latest new files that you need to add to the release cfg
- create a temp cfg based on a PWA
- run the CLT compare -rpCfgPrevRel -rpTempCfgBasedOnLatest
- modify the temp cfg to v1.1 and set the file versions back to the versions in your previous release with exceptions of
of what files and versions you need in the next release.
- save
- Create your real configuration from the twiddled temp cfg.
- done
The reason why we use the temp cfg is that we never version a cfg. Our release cfg's are always version 1.0.
This is mainly folklore, since we name the cfg for the ear name;
product-v10-04102003 which is the date at the end. So there will never be version 1.1
of this cfg given the v10 and date.
I've writen all this down for developers to faithfully reproduce and you may email me for a copy.
[email protected]
Good luck curt