SVN import with unusual structure of Eclipse projects
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:
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
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
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
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.
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:
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 likefolderX
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
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:
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
Yes, you would need to import this by mapping the project folder (e.g. trunk) to the component root folder.
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.
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.
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:
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?
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?
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
There's still maybe an issue.
Contemplate 100's of Eclipse projects, each having the structure:
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.
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.