Workbench and Configuration Managment
Michael R. Kesti
to VxWorks v6.5/Workbench v2.6.1. I have ported two of our MPC860T BSPs
and am generating example workspaces and projects that will be used as the
basis of products to be developed.
I've brought things along well enough to the point where I am beginning
to consider configuration management (CM) issues. According to section
28.2.1 of the Workbench User's Guide 2.6, VxWorks Version, one should
submit one's source files along with .project, .wrproject, .wrfolder,
.wrmakefile, *.makefile, and *.wpj files to CM control. Further, the
manual states, "NOTE: The .metadata directory should not be version
controlled, as it contains mostly user- and workspace-specific information
with absolute paths in it.
So I added the indicated files to our CM system and then, to simulate
co-workers loading the controlled files their first time I deleted all
files from my workspaces, reloaded those workspaces from CM, and restarted
Workbench. To my great dismay, I found that Workbench no longer contained
my workspaces' projects!
It seems, then, that there are files under the .metadata folder that
need to be controlled, but not all of them as simply opening a workspace
modifies some of them. Further, some files seems to come and go. For
example, files named *.tree, so far with single digit base names such as
6.tree, 7.tree and the like, seem to appear and vanish under conditions
that I have not been able to identify.
If there is anybody out there that has been through this and figured out
a CM approach that works for you under Workbench, I would very much like
to learn what you are doing!
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mrkesti at hotmail dot com | - The Who, Bargain
Johnny Willemsen
From what we got back from WindRiver is that the workspace is user specific
and can't be put under version control. Each user has to maintain their own
workspace. We also do see this as bug, please report this as TSR to
WindRiver, if they accept your bug let me know the enhancement request they
created.
Johnny WIllemsen
"Michael R. Kesti" <michae...@nospam.net> wrote in message
news:47BA5661...@nospam.net...
gvarndell
wrote:
What we do is fairly simple but adequate.
We use Clearcase and have added the cc plugin to Workbench.
One developer creates a project in his own workspace and, when he's
ready to cm, enables the cc plugin.
At this point, you can right click on the project you want to cm,
select team->Share Project, and put the project under cm.
The project will be removed from your workspace after this, so it's a
good idea to make a copy of the project directory.
Other developers then just import the project from the cc view using
Import->General->Existing Projects into Workspace.
There are problems. For instance, the project build spec is always
reset to default on import.
Making matters worse, there are so many ways you can structure a
project.
For simplicity, we build our projects in the workspace with external
content.
Sub-projects seem to be handled fairly well -- with proper path
translation being taken care of for you -- so long as you 'share' all
projects and sub-projects at the same time.
I will say that is probably impossible to be successful at this
without getting familiar with Workbench projects files.
They are XML and not that hard to understand.
Every project I share, I save a copy first and then compare to the
cm'd project just to see what sharing it did.
HTH
GV