Hierarchical component organization

I know this question is rather old but in 6.0.2 you can do a 'add sub-component' when components are in your repository workspace.

Currently, there is no way to define a hierarchical structure of
components. The work item requesting this functionality is 2127.
Please feel free to add your interest/support via a comment on this work
item.

Note though that many projects will share components, so that a few
dozen components, each with a handful of components, does not
necessarily result in hundreds of components. Also note that the number
of components is significantly affected by the granularity of your
components (i.e. how many files/projects are in each component).
Because files do not move across components as smoothly as they move
within components, there is semantic motivation not to make your
components too fine-grained.

Cheers,
Geoff

williambyrne wrote:

Hierarchical component organization - does it exist?

I'm looking to import a few projects and it seems like they'll appear
as a flat list within the Components node of the RTC client.

If I accumulate a few dozen projects, each with a handful of
components, will I end up with a flat list of a few hundred component
entries?


If it is indeed flat, would it make sense to adopt the Directory
Service paradigm where objects are uniquely identified; yet, free to
be located in arbitrary directories?

Similar concerns exist for streams.

Currently, there is no way to define a hierarchical structure of
components. The work item requesting this functionality is 2127.
Please feel free to add your interest/support via a comment on this work
item.

Thank you.


The Composite concept referenced in 2127 is interesting though not necessarily a byproduct of Directory structured components. Groups would probably be better notation than Composites in the world of Directory structures since I imagine compositing is a function of Streams.

There should be no additional processing rules to accommodate Directory structured component organization other than the logic required to locate a specific component (e.g., LDAP, NDS path notation). Groups are simply dumb containers that simplify the organization of Components.

Note though that many projects will share components, ...

That's debatable. The shop might be managing a few hundred projects with some degree of component share, but not with a broad range of commonality between the projects.


Not only could the component list get large, but also My Repository Workspaces will also grow as a vertical list, instead of an structured hierarchy.

Maybe I'm looking at the RTC incorrectly. I have some expectations with respect to the traditional software project layout on disk, and the many SVN/CVS repositories available for a given host. I could be wrong, but it seems like RTC was designed to host a minimal set of projects and components.

Regardless of this issue, We're committed to using RTC. It's an awesome product with great potential.

Comments below:

williambyrne wrote:

gmclemmwrote:

Note though that many projects will share components, ...

That's debatable. The shop might be managing a few hundred projects
with some degree of component share, but not with a broad range of
commonality between the projects.

I didn't mean to imply that in all cases, many projects will share
components, but rather that in many cases, projects will share
components, either because the company explicitly encourages re-use
between projects, or because there are many projects working in parallel
on a common system.

But that is an observation across a wide range of customers ... it can
easily not be the case for a particular customer.

Maybe I'm looking at the RTC incorrectly. I have some expectations
with respect to the traditional software project layout on disk, and
the many SVN/CVS repositories available for a given host. I could be
wrong, but it seems like RTC was designed to host a minimal set of
projects and components.

Yes, that would be wrong (:-). RTC is designed to host a large number
of projects and components in a single repository (and in each release,
we increase the scalability of the RTC repository). In particular, you
will commonly find that you would import all of your SVN and CVS
repositories into a single RTC repository. (And as above, that is a
general observation ... there will always be exceptions where more than
one RTC repository would be used).

Regardless of this issue, We're committed to using RTC. It's an
awesome product with great potential.

That's great to hear!

Cheers,
Geoff

To clarify, workitem 2127 is not stream-based component composition, but
rather a way to treat a group of components semantically as a single
component.

I agree that it is much simpler to just provide a hierarchical namespace
for components, without the semantics of composition. One of the main
reasons is that with composition, it is important that two different
composite components be able to contain a commmon sub-component. But
with a hierarchical namespace, each component has a single parent.

Cheers,
Geoff

williambyrne wrote:

gmclemmwrote:
Currently, there is no way to define a hierarchical structure of
components. The work item requesting this functionality is 2127.
Please feel free to add your interest/support via a comment on this
work
item.


Thank you.


The Composite concept referenced in 2127 is interesting though not
necessarily a byproduct of Directory structured components. Groups
would probably be better notation than Composites in the world of
Directory structures since I imagine compositing is a function of
Streams.

There should be no additional processing rules to accommodate
Directory structured component organization other than the logic
required to locate a specific component (e.g., LDAP, NDS path
notation). Groups are simply dumb containers that simplify the
organization of Components.

Geoff, I'm not aware of any way to move files across components (smoothly or otherwise), at least not "move" in the SCM sense. Is there any way to move files across components (and preserve version history)?

thanks,
-Sky

Currently, there is no way to define a hierarchical structure of
components. The work item requesting this functionality is 2127.
Please feel free to add your interest/support via a comment on this work
item.

Note though that many projects will share components, so that a few
dozen components, each with a handful of components, does not
necessarily result in hundreds of components. Also note that the number
of components is significantly affected by the granularity of your
components (i.e. how many files/projects are in each component).
Because files do not move across components as smoothly as they move
within components, there is semantic motivation not to make your
components too fine-grained.

Cheers,
Geoff

You can use the standard Eclipse "refactor -> move" operation to move a
file across components. The history isn't moved, but a back pointer is
created from the new history back to the old history. So history is
reasonably well preserved, but note that change-sets with changes of the
file at it's old location are not applied to the file at its new location.

Cheers,
Geoff

sky wrote:

Geoff, I'm not aware of any way to move files across components
(smoothly or otherwise), at least not "move" in the SCM
sense. Is there any way to move files across components (and preserve
version history)?

thanks,
-Sky

gmclemmwrote:
Currently, there is no way to define a hierarchical structure of
components. The work item requesting this functionality is 2127.
Please feel free to add your interest/support via a comment on this
work
item.

Note though that many projects will share components, so that a few

dozen components, each with a handful of components, does not
necessarily result in hundreds of components. Also note that the
number
of components is significantly affected by the granularity of your
components (i.e. how many files/projects are in each component).
Because files do not move across components as smoothly as they move

within components, there is semantic motivation not to make your
components too fine-grained.

Cheers,
Geoff

Thanks Geoff, I thought only refactor at the Eclipse project level worked, so good to know about the pointer. I'll have to experiment, but that should work for me for now.

-Sky

You can use the standard Eclipse "refactor -> move" operation to move a
file across components. The history isn't moved, but a back pointer is
created from the new history back to the old history. So history is
reasonably well preserved, but note that change-sets with changes of the
file at it's old location are not applied to the file at its new location.

Cheers,
Geoff

sky wrote:

Geoff, I'm not aware of any way to move files across components
(smoothly or otherwise), at least not "move" in the SCM
sense. Is there any way to move files across components (and preserve
version history)?

thanks,
-Sky

gmclemmwrote:
Currently, there is no way to define a hierarchical structure of
components. The work item requesting this functionality is 2127.
Please feel free to add your interest/support via a comment on this
work
item.

Note though that many projects will share components, so that a few

dozen components, each with a handful of components, does not
necessarily result in hundreds of components. Also note that the
number
of components is significantly affected by the granularity of your
components (i.e. how many files/projects are in each component).
Because files do not move across components as smoothly as they move

within components, there is semantic motivation not to make your
components too fine-grained.

Cheers,
Geoff