It's all about the answers!

Ask a question

How to split/divide exiting RTC component into new ones?


Guowei Jim Hu (1.0k710353) | asked Feb 04 '10, 3:11 p.m.
Does RTC scm has the functionality somewhere to allow user to split/merge exiting components into new ones?

Say I have one component A with three top folders f1, f2, f3 and I want to created three new components and each will just hold one of them and maintain the original history in A.

I don't see a direct way to do it except the Replace with command.


Is it possible to just create anew component and move a whole folder from another component into it?

Accepted answer


permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 09 '10, 11:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, you can do the refactoring after the import.
The history will not actually get moved to the new component, but a
backlink to the imported history will be stored with the versionable in
the new component.

And the refactoring works on any files and directories, not just Java
source code.

Cheers,
Geoff

ghu wrote:
gmclemmwrote:
Could you expand a bit on what you mean by "handle"? In
particular,
what are the operations that you want to apply to the imported
components, or what is the result that you want to achieve?

Cheers,
Geoff



Geoff,
After the import is done, I will have one RTC component contain all
the folder and files from SVN. My customr then want to move some of
the folders and files into new components.

I guessI can use Team->Move or Refactor to move them between
omponents without worying about the history and links? Are they only
work fr Java code?
Ralph Schoon selected this answer as the correct answer

20 other answers



permanent link
Setembrino Lusa (54) | answered Sep 28 '16, 4:45 p.m.
 https://jazz.net/help-dev/clm/index.jsp?topic=%2Fcom.ibm.team.scm.doc%2Ftopics%2Ft_scm_eclipse_mv_project.html

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 30 '11, 7:10 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Jay,

I added a comment to that work item ... see if that answers your
question (let's continue the discussion in that work item).

Cheers,
Geoff

On 8/28/2011 2:23 PM, jaybrubin wrote:
Geoff is this RFE not a valid process usuage:

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=175331

Work Item = 175331

"can their be a simple way we can clone a clone repository
workspace / component that will have no linkages to the source
component we want to clone. happy to use snapshots or flow targets;
but don't want connected baselines after clone. command line is fine
too."

is this eclipse move folder something to investigate?

permanent link
jay brubin (2144) | answered Aug 28 '11, 2:07 p.m.
Geoff is this RFE not a valid process usuage:

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=175331

Work Item = 175331

"can their be a simple way we can clone a clone repository workspace / component that will have no linkages to the source component we want to clone. happy to use snapshots or flow targets; but don't want connected baselines after clone. command line is fine too."

is this eclipse move folder something to investigate?

permanent link
Jirong Hu (1.5k9290258) | answered Aug 26 '11, 12:03 p.m.
Hi

I used "Move into Repository" to move three root folders in one component to three other components. Basically I split one component with 68K files and folders into four components, in fear of performance issues.

Now there are two components, Client and Server still have 20~30K files and folders. I notice Deliver and especially Accept take a few minutes, e.g. after create a new snapshot in workspace.

My questions is: does split help in performance or still constrained by the original 68K files in the original component, due to maybe a link back to the original component. Shall I delete everything and re-import the files?

Do you have 30K files in one component?

Thanks
Jirong

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 02 '11, 8:46 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, if you have several (non-root) folders that you want to move to
another component, first moving them all to some dummy root folder in
the source component would require fewer operations (you just have to
remember where you wanted each of those folders to end up in the
destination component).

WRT creating a baseline in the source component, it is very easy in RTC
to back-up to an earlier configuration of a component ... just
discard/suspend the change sets involved in the move ... but it never
hurts to create a baseline as well.

Cheers,
Geoff

On 8/2/2011 4:23 AM, dmaaren wrote:
Hello Geoff,

This discussion was very helpfull to me to move files between
components.
I think a little improvement is possible regarding your workaround.
What about creating a dummy root folder in the source component. Then
you can move all the files you want to transfer in this dummy root
folder.
After the "Move in repository" action (of this dummy root
folder), you don't need to bother anymore about the source
component.
Also I think it's wise to make a pre-move baseline of the source
component, before starting the whole operation.
If something goes wrong, you can always revert to this baseline.

Greetings,
Dick van Maaren.
gmclemmwrote:
Please see the correction I posted to my earlier posting. To
summarize
the correction, backlinks are only created by the "move in
repository"
operation, not the Eclipse "move" operation.

Also, note that the way the GUI displays these backlinks is to have
a
"break" in the history line that is drawn to the left in
the "history"
view on a file. That "break" represents the backlink to
the earlier
history of that file in another component.

Cheers,
Geoff

ghu wrote:
gmclemmwrote:
Yes, you can do the refactoring after the import.
The history will not actually get moved to the new component, but a

backlink to the imported history will be stored with the
versionable
in
the new component.

And the refactoring works on any files and directories, not just
Java
source code.

Cheers,
Geoff



Geoff,
Can you explain a little more on the history backlink as we can't
see
any imported history or link for files moved to the new component?


permanent link
Dick van Maaren (6) | answered Aug 02 '11, 4:19 a.m.
Hello Geoff,

This discussion was very helpfull to me to move files between components.
I think a little improvement is possible regarding your workaround.
What about creating a dummy root folder in the source component. Then you can move all the files you want to transfer in this dummy root folder.
After the "Move in repository" action (of this dummy root folder), you don't need to bother anymore about the source component.
Also I think it's wise to make a pre-move baseline of the source component, before starting the whole operation.
If something goes wrong, you can always revert to this baseline.

Greetings,
Dick van Maaren.
Please see the correction I posted to my earlier posting. To summarize
the correction, backlinks are only created by the "move in repository"
operation, not the Eclipse "move" operation.

Also, note that the way the GUI displays these backlinks is to have a
"break" in the history line that is drawn to the left in the "history"
view on a file. That "break" represents the backlink to the earlier
history of that file in another component.

Cheers,
Geoff

ghu wrote:
gmclemmwrote:
Yes, you can do the refactoring after the import.
The history will not actually get moved to the new component, but a

backlink to the imported history will be stored with the versionable
in
the new component.

And the refactoring works on any files and directories, not just
Java
source code.

Cheers,
Geoff



Geoff,
Can you explain a little more on the history backlink as we can't see
any imported history or link for files moved to the new component?

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 20 '10, 1:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Since you posted the request against RTC, they assumed you were
referring to the "move in repository" operation (which is an RTC
operation), as opposed to the "move" operation (which is an Eclipse
operation, that is enhanced by RTC, but whose core semantics are defined
by Eclipse, not RTC).

And work item 21637 does ask for the functionality you describe in
106422, so marking it as a duplicate was correct (as long as this is
interpreted as asking for enhanced functionality from the "move in
repository" operation).

Cheers,
Geoff

ghu wrote:
gmclemmwrote:
This is an Eclipse command, not an RTC command, so you'd have to
submit
this request at www.eclipse.org.

Cheers,
Geoff



Oops! I've created one
(https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/106422
) but it was closed as a duplicate of another
one:https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/21637

I guess I didn't put it clear enough:)

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 20 '10, 1:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Please see the correction I posted to my earlier posting. To summarize
the correction, backlinks are only created by the "move in repository"
operation, not the Eclipse "move" operation.

Also, note that the way the GUI displays these backlinks is to have a
"break" in the history line that is drawn to the left in the "history"
view on a file. That "break" represents the backlink to the earlier
history of that file in another component.

Cheers,
Geoff

ghu wrote:
gmclemmwrote:
Yes, you can do the refactoring after the import.
The history will not actually get moved to the new component, but a

backlink to the imported history will be stored with the versionable
in
the new component.

And the refactoring works on any files and directories, not just
Java
source code.

Cheers,
Geoff



Geoff,
Can you explain a little more on the history backlink as we can't see
any imported history or link for files moved to the new component?

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 20 '10, 1:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A correction/clarification to one of the points I made below.
In particular, I said:

you can use the plain old "Move" command
to move the file/folder wherever you want
in the other component.

Although that statement is true, it is misleading because the plain old
"Move" command when used to move a file/directory to another component
does *not* create the back-pointer to the previous history. I've just
added a comment to work item 56504, asking that it do so.

So the only way I know of to move files/folders across components while
creating history back-pointers is to use the "move in repository"
operation ... and that operation appears currently to only be supported
on root folders within a component (i.e. folders that are logically
immediate children of the logical component root folder).

So until work item 56504 is implemented, the only workaround I can think
of to achieve this cross-component move of selected files/folders while
creating history back-pointers, is:
- use "move in repository" to move the tree containing the file/folders
you wanted to move into the destination component. This will create the
tree as a new root folder in the destination component.
- use regular "move" to move the file/folders where you really wanted
them to move within the destination component.
- use "delete in repository" to delete the tree in the destination
component.
- in the source component, discard the "move in repository" change set
(this will cause that tree to reappear).
- in the source component, delete the files/folders that you moved to
the destination component.

If anyone knows of a simpler workaround, please post it.

Cheers,
Geoff

Geoffrey Clemm wrote:
Comments below:

ghu wrote:
Geoff,
I finalyy get the imaport done and tried the refactoring and got
confusing results.

RTC offers Move and Move in Repository commands for moving projects
and source folders around.
It looks like when one wants to move source folder from one component
to another component, one has to first load the folder into a Eclipse
project to enable the Move in Repository command.

Correct.

The Move command seems to be only work for moving source folders around
in the same component.

What makes you think that? You do have to have both components loaded
as projects in Eclipse, but then you should be able to use the Move
command.

The issue is that when you load one source folder into an Eclipse
project , it becomes the top folder nomatter how deep it was located
in the original source tree.

That is controlled by the "Load" option you use. To load the entire
component, use the "Load the root folders as components" option. Note
that what makes this a bit confusing is that the standard Eclipse views
like the "package explorer" or "project explorer" only work against
Eclipse projects (i.e. directories that contain a .project file), rather
than arbitrary trees on disk. So this option "fakes it", by pretending
that the root directory of the component is in fact an Eclipse project
(you'll see that it creates a .project file for you in the root
directory of the component, to make Eclipse happy).

And then if you use Move in Repository
to move the folder into a new component, it is created as the top
folder there too.

If you use the above technique to load the entire component, you can use
the plain old "Move" command to move the file/folder wherever you
want in the other component.

So if one wants to preserve the original path, then has to create them
manually before the move. And this seems necessary when you have to
move folders with the same name and you don't want to change the name
in the new component.
Here is one example. I have in the original component two folders
/src/discovery and /src/java/com/ibm/discovery and need to move them
both to a new component. I can't load them into the same project due
to name confliction, and after load them into two projects, I can
only move one of them into the new component using Move in Repository
due to name confliction. I'll have to either rename one of them or
manualy create the path in the new component first.
But will this break the integraty of the source tree structure and
build?
Do I miss or do something wrongly here to get into this?

Try the approach I describe above, and things should work better for
you. One important note: Before you "complete" or "deliver" the
change set that results from checking in your various move/rename
operations, do the following:
- unload the two components
- open up the change set in each component, and find that fake
".project" file that was created in the root directory of each component
(to make Eclipse happy), and "undo" it (i.e. undo just the addition of
the root ".project" files).
Otherwise, you'll find a bogus ".project" file has been created in the
repository in the root of your components.

I've submitted work item 106037, asking for a way to load these kinds of
components into Eclipse, without the creation of the bogus .project
files in the component root directory.

Cheers,
Geoff

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.