I setup a workspace using the procedure outlined in this thread. The end
result that I get has the root and modules in a flat layout (not
hierarchical) like this:
root
module1
module2
module3
At first I thought that it didn't work for me, but I suspect that this
was the same result that others got. I was expecting a hierarchical
layout in Eclipse, but I see now that this is really just a trick that
allows you to create overlapping Eclipse projects. Normally, Eclipse
would not allow you to add both "root" and "module1" projects to the
same workspace, since they overlap.
Eclipse creates the projects as you describe above, but the actual
contents of moduleX is contained within root. As you noted.
3. You can commit changes in multiple modules/projects in one
transaction, by committing the changes from root project. (However, I
see now that the Subversive subversion plugin supports "cross project
atomic commits", which sounds like it will work even if you don't have
your project root setup as an Eclipse project.)
At the moment I am using CVS, so I haven't noticed this issue.
But it is still lacking in several respects:
1. If one team member adds a module, every person on the team has to do
some fiddling to setup their workspace.
Only if that person wants to work on that module.
It's a small price to pay.
You really only want to create projects in your eclipse workspace on
stuff you are actually working on anyway.
2. The display in Eclipse is still flat, rather than hierarchical,
making it impractical to have more than one multi-module project in the
same workspace (since there is no indication which "root" project owns
"moduleX").
In the Package Explorer there is a down arrow in the view toolbar,
choose "Select Working Set..." from it and you can then group your
projects together into whatever logical organisation you want.
Alternatively create more than one workspace if the projects are not related.
3. You are limited to one level of inheritance in your project
hierarchy. Or maybe not, if you do the same .project-hide and import
trick more than once. Whatever the case, it still flattens the view.
The project can be setup at any level of subdirectory below the root.
I think what you might be talking about is
root
- groupingA
- moduleX
- moduleY
- groupingB
- module G
I don't have such a structure but I see no reason why you could not
create a project for groupingA, moduleX and moduleY.
4. All of your files show up twice (or worse, if your project hierarchy
has more than one level) -- once as root/moduleX/file and again as
moduleX/file. This can be confusing. The double-display of file
modification label decorations is annoying. I suspect that it also has a
significant negative impact on Eclipse performance.
I doubt the impact is significant enough to worry about.
And you would soon get over the confusing part.
If for some reason there is a performance penalty, you can always go
back to having a single project. For me the benefits far outway any
drawbacks.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
