It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×11,924
×1,198
×889
×9

question asked: Feb 13 '10, 4:22 a.m.
question was seen: 8,302 times
last updated: Jul 11 '16, 10:44 a.m.

Related questions

FAQ - How this Forum works

Hierarchical component organization

0
William Byrne (55●4●5) | asked Feb 13 '10, 4:22 a.m.
edited Jul 11 '16, 10:39 a.m. by David Lafreniere (4.8k●7)
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.

Accepted answer

0
permanent link
Peter Bouten (68●1●7) | answered Jul 11 '16, 5:24 a.m.
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.
Ralph Schoon selected this answer as the correct answer
Comments
David Lafreniere commented Jul 11 '16, 10:44 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

Component Hierarchies were added in RTC 6.0. This lets you create a component hierarchy structure that is visible in the Team Artifacts view and the Pending Changes view. You can add a subcomponent in the Eclipse or Visual Studio clients, or using the 'add sub-component' command in the CLI.


Once done, you can perform actions such as "Accept from Hierarchy" or "Deliver to Hierarchy" on root components nodes; also the entire component hierarchy configuration is automatically captured when you create a baseline on 'root' components.

Currently this hierarchy does not impact how the components actually get loaded (i.e their placement on disk). The user is free to choose how to load these (whether folders be laid out flat on disk, or in a hierarchy, or whether or not certain components are to be loaded and not others, etc.) using load rules.

8 other answers

Most liked answers ↓|Newest answers|Oldest answers

0
permanent link
Sky Matthews (36●3●2) | answered Feb 17 '10, 3:01 p.m.
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


0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Feb 16 '10, 9:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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
0
permanent link
Sky Matthews (36●3●2) | answered Feb 16 '10, 9:38 a.m.
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

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Feb 14 '10, 10:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Feb 14 '10, 10:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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
0
permanent link
William Byrne (55●4●5) | answered Feb 14 '10, 2:24 p.m.

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.
0
permanent link
William Byrne (55●4●5) | answered Feb 14 '10, 2:07 p.m.
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.
0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Feb 13 '10, 10:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.