It's all about the answers!

Ask a question

SVN import with unusual structure of Eclipse projects


Marshall Schor (1012724) | asked May 03 '11, 9:41 a.m.
The help and wiki ( https://jazz.net/wiki/bin/view/Main/ ) describes how to do this for a standard configuration in SVN, where the SVN looks like:

 trunk

folderX
folderY
folderZ
branches
branch1
folderX
folderY
folderZ
tags
tag1
tag2
etc.


An unwritten assumption in the above I think, is that the "folderX", "folderY", "folderZ" are the individual (Eclipse) projects. This is not how our SVN is laid out.

We have an SVN structure where each Eclipse project folder has (in SVN) its own trunk, tags, and branches. We routinely tag individual projects to mark integration levels. It looks like

folderX

trunk
.project (for the Eclipse project of folderX)
.classpath
src etc
branches
branch1
.project
.classpath
src etc
branch2 (etc.)
tags
tag1
.project
.classpath
src etc
tag2
etc.
etc.

folderY (another Eclipse project)
etc.

folderZ (another Eclipse project)
etc.


Can this structure be imported into RTC?

Would the right approach be to create "components": 1 for each Eclipse project? (That way, it seems, we could emulate creating a "baseline" for each Tag).

-Marshall Schor

9 answers



permanent link
Michael Valenta (3.7k3) | answered May 03 '11, 1:59 p.m.
FORUM MODERATOR / JAZZ DEVELOPER


Can this structure be imported into RTC?

Would the right approach be to create "components": 1 for each Eclipse project? (That way, it seems, we could emulate creating a "baseline" for each Tag).

-Marshall Schor


Yes, you would need to import this by mapping the project folder (e.g. trunk) to the component root folder.

permanent link
Geoffrey Clemm (30.1k33035) | answered May 03 '11, 11:01 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, you could create component for each project, but that would
probably produce an excessively large number of components.
Unless you count on the ability to select an arbitrary tag for each
project to compose your configuration, the stream for a .psf file
approach is simpler.

Cheers,
Geoff

On 5/3/2011 9:53 AM, marshallschor wrote:
The help and wiki ( https://jazz.net/wiki/bin/view/Main/ ) describes
how to do this for a standard configuration in SVN, where the SVN
looks like:

trunk
folderX
folderY
folderZ
branches
branch1
folderX
folderY
folderZ
tags
tag1
tag2
etc.

An unwritten assumption in the above I think, is that the
"folderX", "folderY", "folderZ" are the
individual (Eclipse) projects. This is not how our SVN is laid out.


We have an SVN structure where each Eclipse project folder has (in
SVN) its own trunk, tags, and branches. We routinely tag individual
projects to mark integration levels. It looks like

folderX
trunk
.project (for the Eclipse project of folderX)
.classpath
src etc
branches
branch1
.project
.classpath
src etc
branch2 (etc.)
tags
tag1
.project
.classpath
src etc
tag2
etc.
etc.

folderY (another Eclipse project)
etc.

folderZ (another Eclipse project)
etc.


Can this structure be imported into RTC?

Would the right approach be to create "components": 1 for
each Eclipse project? (That way, it seems, we could emulate creating
a "baseline" for each Tag).

-Marshall Schor

permanent link
Marshall Schor (1012724) | answered May 04 '11, 4:44 p.m.
Hmmm. Saying this can be done, seems to conflict with the help I found for version 3.0, which said:

Note:
Repository organizations where the trunk folder itself maps to an Eclipse project are uncommon and are not supported by the importer:
   trunk

src
.classpath
tags
branches


We're planning to work around this by making a new node in our SVN and "copying" the data, to conform to the style which is supported by the RTC import capability.

-Marshall


Can this structure be imported into RTC?

Would the right approach be to create "components": 1 for each Eclipse project? (That way, it seems, we could emulate creating a "baseline" for each Tag).

-Marshall Schor


Yes, you would need to import this by mapping the project folder (e.g. trunk) to the component root folder.

permanent link
Michael Valenta (3.7k3) | answered May 05 '11, 10:43 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Hmmm. Saying this can be done, seems to conflict with the help I found for version 3.0, which said:

Note:
Repository organizations where the trunk folder itself maps to an Eclipse project are uncommon and are not supported by the importer:
   trunk

src
.classpath
tags
branches


...


What doc was this? It wasn't supported initially (1.0) but should certainly work now. Let me know the documentation you were referring to so I can make sure it gets updated.

P.S. I'm pretty sure your work around would lose the history for the items being imported.

permanent link
Kevin Behrens (7132) | answered May 05 '11, 11:05 a.m.
I believe the layout Marshall describes, we'll call this the project-trunk layout (the eclipse .project is immediately /trunk) is much more common and conceptually cleaner (especially for java projects built with maven - where ingesting artifacts from different projects is trivial) than the projects-as-branch-siblings layout described as 'most common' in the online help and given as an example in the jazz.net wiki.
I believe it's cleaner as a project is something that is built, versioned, tagged and released as a unit. It seems odd to me to checkout multiple projects just to build one, or tag multiple projects at a go.


From the svn book:

In the name of full disclosure, though, we'll mention another very common layout. In this layout, the trunk, tags, and branches directories live in the root directory of your repository, and your projects are in subdirectories beneath those, like so:

/
trunk/
calc/
calendar/
spreadsheet/

tags/
calc/
calendar/
spreadsheet/

branches/
calc/
calendar/
spreadsheet/

There's nothing particularly incorrect about such a layout, but it may or may not seem as intuitive for your users. Especially in large, multiproject situations with many users, those users may tend to be familiar with only one or two of the projects in the repository. But the projects-as-branch-siblings approach tends to deemphasize project individuality and focus on the entire set of projects as a single entity. That's a social issue, though. We like our originally suggested arrangement for purely practical reasonsit's easier to ask about (or modify, or migrate elsewhere) the entire history of a single project when there's a single repository path that holds the entire historypast, present, tagged, and branchedfor that project and that project alone.


I'm very new to svn, but I'm having a hard time seeing a situation where I'd want more than one eclipse project per component, or have more than component per project. Thoughts?

permanent link
Marshall Schor (1012724) | answered May 05 '11, 2:10 p.m.
Hmmm. Saying this can be done, seems to conflict with the help I found for version 3.0, which said:

Note:
Repository organizations where the trunk folder itself maps to an Eclipse project are uncommon and are not supported by the importer:
   trunk

src
.classpath
tags
branches


...


What doc was this? It wasn't supported initially (1.0) but should certainly work now. Let me know the documentation you were referring to so I can make sure it gets updated.

P.S. I'm pretty sure your work around would lose the history for the items being imported.

The doc is here:

http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0/index.jsp?topic=/com.ibm.team.scm.svn.doc/topics/c_svn.html

scroll down to the first "Note:"

-Marshall

permanent link
Michael Valenta (3.7k3) | answered May 06 '11, 8:45 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
I have entered https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/164821 to request that the note be removed since that scenario is now supported.

permanent link
Marshall Schor (1012724) | answered May 07 '11, 8:39 a.m.
There's still maybe an issue.

Contemplate 100's of Eclipse projects, each having the structure:

proj-name

trunk
.project, src/ etc.


Is this the process that would be needed:

1) select a particular proj-name/trunk in the import
2) import into a component (resulting in the component having a new top-level folder, called "trunk"
3) do some action to rename the component top level folder "trunk" back to proj-name

repeat the above for the 100's of projects, each individually.



I have entered https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/164821 to request that the note be removed since that scenario is now supported.

permanent link
Michael Valenta (3.7k3) | answered May 09 '11, 10:42 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
I think it would be worthwhile to capture this in an enhancement request against RTC Source Control.

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.