Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Momentics Workspace Control Files: (12 Items)
   
Momentics Workspace Control Files  
Which workspace and project files require source control? 

We are using Microsoft's VSS tool, therefore don't expect it to integrate into Momentics, but still need to do version 
and backup control manually. It is apparent the .cdtbuild, .cdtproject, and .project files in each project directory 
require control, but the .metadata directory tree is loaded with directories and files which probably don’t require all
 to be under control. 

Can someone please list the files required to transport the workspace and associated projects to another computer?
Re: Momentics Workspace Control Files  
There is a VSS plugin for Eclipse which you could try:
http://sourceforge.net/projects/vssplugin/

There maybe others, a quick Google search should help.

Any of the .* files tend to be user and machine specific and don't work well in source control. If you really need to 
share these files you might want to do that outside of source control - again, this is still tricky because these files 
are user and machine specific.

Momentics 6.3.2 is based on Eclipse 3.2 and Tau is based on version 3.3 - you can search for help on VSS and other 
things based on what works for Eclipse.
Re: Momentics Workspace Control Files  
This is actually even better. If you use this plugin you can use team projects set to define what projects to check out.
RE: Momentics Workspace Control Files  
To move all projects without version control you can Export them using
File->Export... menu and import on another machine. Copy workspace may work
as well.

If you talking about version control it is generally good idea to put all
files inside each project in version control (including .xxx files), in this
case when you check out project eclipse has all settings for it that it
needs.
Also some people prefer to keep launch configuration inside the project as
well and check them in version control (to do this you need to make
configuration "shared" and select project as a location for it)
.metadata directory usually contains personal preferences and histories and
not need to be in version control.
Re: RE: Momentics Workspace Control Files  
Thank you, but one more question:

How dows the workspace know what projects are included ... by the file structure allone? In other words, if developer A 
adds a new project to the work space, and developer B retrieves the new sub-directory from version control, will his 
workspace automatically reflect the new project? 
RE: RE: Momentics Workspace Control Files  
No, eclipse keeps information of what projects are in workspace in one of
the files in .metadata. If you do it manually you would have to check out
project first in workspace and than add it as general project (New->Project)
and give exact name as in file system. Eclipse would open project and assign
correct type using .project file if it is there. 
Re: RE: RE: Momentics Workspace Control Files  
This is what I thought, therefore the same question ... what files in the .metadata directory are needed in source 
control?
RE: RE: RE: Momentics Workspace Control Files  
None of them. These files are user preferences. You cannot force all people
have exactly same projects in workspace, and override their own projects
when they check out.
Re: RE: RE: RE: Momentics Workspace Control Files  
Really ... that’s terrible!

How is one supposed to manage a multi-developer project? It is very common to have different developers work on 
different projects therefore each could not see the result of each other without some external communication channel. If
 co-dependencies occur the problem gets very complicated. If an outside developer wants to look at the workspace how 
would he even know what projects are contained?

We must be missing something, that would not be workable.
RE: RE: RE: RE: Momentics Workspace Control Files  
Sorry I think I misunderstood what you asking. The only thing which would
not be controlled is how many project you have and what they are (at top
level). If you have shared project you can always see what was changed
inside using version control.
I personally use integrated version control such as svn and cvs plugins.
You can check internet to see plugins for you specific version control.

So if you are NOT using integrated plugins you can check it within your
version control directly.

I will use cvs example: You have directory (module) that matches workspace,
for example "router_code". It will contain top level projects entry
"project1", "project2", etc.

So to check all projects out type 
cvs co router_code
ls router_code
router_code/project1 router_code/project2

Now go to eclipse, start it with router_code as workspace and add these 2
projects. When later if you do update you have to refresh workspace only.
Also in this case you have to add .metadave to .cvsignore because this one
should not be committed.


-----Original Message-----
From: david diprato [mailto:ddiprato@novusxray.com] 
Sent: February 28, 2008 12:06 PM
To: momentics-community
Subject: Re: RE: RE: RE: Momentics Workspace Control Files

Really ... that's terrible!

How is one supposed to manage a multi-developer project? It is very common
to have different developers work on different projects therefore each could
not see the result of each other without some external communication
channel. If co-dependencies occur the problem gets very complicated. If an
outside developer wants to look at the workspace how would he even know what
projects are contained?

We must be missing something, that would not be workable.


_______________________________________________
QNX Momentics Community Support
http://community.qnx.com/sf/go/post5376
Re: Momentics Workspace Control Files  
To elaborate Elana's post5378 about the "Team Project Set", here is what you need to do in order to share Eclipse 
projects with a groups of developers:

1) You need to install the Eclipse VSS plugin from http://sourceforge.net/projects/vssplugin/, set up the repository 
connection like username and password.

2) Organize your workspace and projects. If you have project specific preferences, make sure you set them on the 
project(s).

3) Check in EVERYTHING within each project directory including all the dot files. Those dot files are required by 
Eclipse to re-construct the project. They are ".project", ".cproject" and ".cdtproject" for C/C++ projects, ".classpath"
 and ".option" for project specific settings.

4) Select from the menu "File -> Export"; in the export wizard select "Team -> Team Project Set". From the list of 
projects choose the ones you want to share. In the final page, save it to a file with ".psf" extension.

5) Share this file with your team members. They also need to have the Eclipse VSS plugin installed. They will use "File 
-> Import" wizard to import from the team project set. Eclipse will check out all the shared projects and set them up 
properly.

Please let us know if you have further question.

Thanks,
Andy
Re: RE: RE: RE: Momentics Workspace Control Files  
On Thu, Feb 28, 2008 at 12:05 PM, david diprato <ddiprato@novusxray.com>
wrote:

> Really ... that's terrible!
>
> How is one supposed to manage a multi-developer project? It is very common
> to have different developers work on different projects therefore each could
> not see the result of each other without some external communication
> channel. If co-dependencies occur the problem gets very complicated. If an
> outside developer wants to look at the workspace how would he even know what
> projects are contained?
>
> We must be missing something, that would not be workable.
>
 Sounds like the problem of source layout and a revision control system,
not what an IDE would manage.

Workspaces are just containers for "stuff" and those containers are
developer
centric (like the way you choose to layout your home directory).
Projects are chunks of data, occasionally related, that teams manage using a
revision
control system (or many revision control systems).

Sure, projects could have interdependencies, but if that is the case, then
isn't
that the role of your build system to be able to identify where those
dependant
pieces are.  If you require a very specific layout, then don't make the
assumption
that the items are in a workspace directory ... projects don't have to be in
the workspace.
If you do that, then you are then treating the workspace as a project.

Make a specific project and if you want to create additional projects that
'point into' that
main project if you need to overcome Eclipses 'sub-project' shortcoming.

You might also be interested in looking at the team export option that
allows you to
create a file that contains references to multiple projects to check out
concurrently.
Like a CVS module, but not revision control system specific.

Thomas