Exception encountered sharing projects

Our development group has recently migrated to RTC 2.0 for project
mgmt and control of our source code. About a month ago I migrated
the sources for our up-coming release into RTC and things went pretty
smoothly. Development is underway, builds are being produced, life is
good! :D

The sources for our currently shipping product are still in our
previous source code control system (ClearCase). We decided last
week to also migrate those sources to RTC, to make it easier to get
bugfixes for the current release into our next release. I know it
would have been easier to migrate the sources for the current release
first, but hindsight is always 20/20.

Following is the procedure I followed. If there is a better way to do
this please reply to this post.

To get the sources for our current release into RTC I created a new
stream for bugfixes of our current release and included many of the
components used by the up-coming release because they both share many
java projects. In the new bugfix stream I set the component baselines
to the Initial baseline. I then created a new Eclipse workspace,
connected to the repository and project, and created a new repository
workspace which flowed to the bugfix stream. I then imported Java
projects from the current release into my Eclipse workspace. I
imported the projects from a copy of a snapshot view to make sure
ClearCase was not in the picture. I then attempted to share the
projects via Team->Share Project->Jazz Source Control. At this
point a dialog was displayed stating the following

Component logview already has content in other sandboxes. This is not
recommended and may result in components becoming out-of-sync when you
deliver changes. Reason: There are several folders being shared to a
component that is present in another sandbox.

The details section of the dialog contained the following.

Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models.hierarchy'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features\com.ibm.rational.test.lt.logviewer.feature'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\com.ibm.rational.test.lt.logviewer'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.hyades.statistical.ui'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'

If I continue on at this point and click OK to share the projects, it
appeared to be processing the share of the projects for about 30
seconds to 1 min. Eventually though it returned a dialog indicating
the share had failed with an internal error. Following is the
trace-back of the exception encountered.

An internal error occurred during: "Sharing Projects".

java.lang.IllegalArgumentException
at
com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2453)
at
com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2426)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.commitChanges(NewCheckInOperation.java:928)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.runRequest(NewCheckInOperation.java:772)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation$1.run(NewCheckInOperation.java:650)
at
com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:421)
at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at
com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:433)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:173)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:153)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.execute(NewCheckInOperation.java:675)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at
com.ibm.team.filesystem.client.internal.share.ShareVersionables.commitNewProjectContents(ShareVersionables.java:176)
at
com.ibm.team.filesystem.client.internal.share.ShareOperation.execute(ShareOperation.java:564)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at
com.ibm.team.internal.filesystem.ui.wizards.sharing.SharingWizard$2.filesystemRun(SharingWizard.java:317)
at
com.ibm.team.filesystem.ui.operations.FileSystemUIOperation.repositoryRun(FileSystemUIOperation.java:43)
at
com.ibm.team.repository.rcp.ui.operations.RepositoryOperation.run(RepositoryOperation.java:42)
at
com.ibm.team.repository.rcp.ui.operations.JobRunner.run(JobRunner.java:205)
at
com.ibm.team.repository.rcp.ui.operations.JobRunner$1.run(JobRunner.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Any "internal error" should be submitted as a work item. Please file it
as a Defect against the "Source Control" category.

WRT what you were trying to do, a key question is what you were trying
to achieve by importing the earlier release. The simplest way to do the
import (that would avoid the bug you encountered) would be to just
import the earlier release into a new component.

In general, there is no way to insert "previous history" into a release
or file. For one thing, since files can get renamed, there's no
generally reliable way to "match up" files from two different releases.

But if you wanted to come "close" (i.e. treat file moves as just
add/delete changes, as CVS would :-) ), and if you didn't care about
carrying forward the change-set history from your current RTC work, you
could:
- import the old release into a new component in a new stream
- have all developers deliver all their work to the current release
- replace all the files in the old release sandbox with the current
files in the current release
- deliver the result to the new component.
- have all your developers switch their workspaces to the new stream
(with the new component).

The new stream wouldn't have the intermediate history of the new
development (you'd have to go to the old stream for that), but it would
have the old release and the new release (and you could for example,
start doing patches to the old release in RTC, and merge them forward to
the new release).

Cheers,
Geoff

tneal wrote:

Our development group has recently migrated to RTC 2.0 for project
mgmt and control of our source code. About a month ago I migrated
the sources for our up-coming release into RTC and things went pretty
smoothly. Development is underway, builds are being produced, life is
good! :D

The sources for our currently shipping product are still in our
previous source code control system (ClearCase). We decided last
week to also migrate those sources to RTC, to make it easier to get
bugfixes for the current release into our next release. I know it
would have been easier to migrate the sources for the current release
first, but hindsight is always 20/20.

Following is the procedure I followed. If there is a better way to do
this please reply to this post.

To get the sources for our current release into RTC I created a new
stream for bugfixes of our current release and included many of the
components used by the up-coming release because they both share many
java projects. In the new bugfix stream I set the component baselines
to the Initial baseline. I then created a new Eclipse workspace,
connected to the repository and project, and created a new repository
workspace which flowed to the bugfix stream. I then imported Java
projects from the current release into my Eclipse workspace. I
imported the projects from a copy of a snapshot view to make sure
ClearCase was not in the picture. I then attempted to share the
projects via Team->Share Project->Jazz Source Control. At this
point a dialog was displayed stating the following

Component logview already has content in other sandboxes. This is not
recommended and may result in components becoming out-of-sync when you
deliver changes. Reason: There are several folders being shared to a
component that is present in another sandbox.

The details section of the dialog contained the following.

Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models.hierarchy'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features\com.ibm.rational.test.lt.logviewer.feature'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\com.ibm.rational.test.lt.logviewer'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.hyades.statistical.ui'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'

If I continue on at this point and click OK to share the projects, it
appeared to be processing the share of the projects for about 30
seconds to 1 min. Eventually though it returned a dialog indicating
the share had failed with an internal error. Following is the
trace-back of the exception encountered.

An internal error occurred during: "Sharing Projects".

java.lang.IllegalArgumentException
at
com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2453)
at
com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2426)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.commitChanges(NewCheckInOperation.java:928)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.runRequest(NewCheckInOperation.java:772)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation$1.run(NewCheckInOperation.java:650)
at
com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:421)
at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at
com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:433)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:173)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:153)
at
com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.execute(NewCheckInOperation.java:675)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at
com.ibm.team.filesystem.client.internal.share.ShareVersionables.commitNewProjectContents(ShareVersionables.java:176)
at
com.ibm.team.filesystem.client.internal.share.ShareOperation.execute(ShareOperation.java:564)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at
com.ibm.team.internal.filesystem.ui.wizards.sharing.SharingWizard$2.filesystemRun(SharingWizard.java:317)
at
com.ibm.team.filesystem.ui.operations.FileSystemUIOperation.repositoryRun(FileSystemUIOperation.java:43)
at
com.ibm.team.repository.rcp.ui.operations.RepositoryOperation.run(RepositoryOperation.java:42)
at
com.ibm.team.repository.rcp.ui.operations.JobRunner.run(JobRunner.java:205)
at
com.ibm.team.repository.rcp.ui.operations.JobRunner$1.run(JobRunner.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Work item 95442 has been submitted. The reason we are trying to
import the previous version is in the hopes that we could then make
changes to the elements/files via the bugfix stream and then more
easily get those changes into sources for our next release. Instead
of having to do it manually by copying changes from our ClearCase
views.

Below you suggest that we create a new set of components (we have 33
components) to hold the file versions from the previous release. If
we did that, how do we get bug fixes from the current release into
the up-coming release? I don't understand how to make the changes
flow into the current set of components holding the sources for our
up-coming release.

If we take the second "come close" suggestion below,
wouldn't the contents of the components be the merging of the current
release code and the up-coming release code? That is great for work
going forward in the up-coming release. But we still need to create
builds that do not contain any of the up-coming code, just the
bugfixes for the current release. ie. two streams/branches of the
elements. Maybe I don't correctly understand how patches work in
RTC.

Maybe we will just have to continue to use CC for bugfixes of the
current release and use RTC for future releases.

Thanks!

--tom

gmclemmwrote:
Any "internal error" should be submitted as a work item.
Please file it
as a Defect against the "Source Control" category.

WRT what you were trying to do, a key question is what you were
trying
to achieve by importing the earlier release. The simplest way to do
the
import (that would avoid the bug you encountered) would be to just
import the earlier release into a new component.

In general, there is no way to insert "previous history"
into a release
or file. For one thing, since files can get renamed, there's no
generally reliable way to "match up" files from two
different releases.
But if you wanted to come "close" (i.e. treat file moves
as just
add/delete changes, as CVS would :-) ), and if you didn't care about

carrying forward the change-set history from your current RTC work,
you
could:
- import the old release into a new component in a new stream
- have all developers deliver all their work to the current release
- replace all the files in the old release sandbox with the current

files in the current release
- deliver the result to the new component.
- have all your developers switch their workspaces to the new stream

(with the new component).

The new stream wouldn't have the intermediate history of the new
development (you'd have to go to the old stream for that), but it
would
have the old release and the new release (and you could for example,

start doing patches to the old release in RTC, and merge them
forward to
the new release).

Cheers,
Geoff

tneal wrote:
Our development group has recently migrated to RTC 2.0 for project
mgmt and control of our source code. About a month ago I migrated
the sources for our up-coming release into RTC and things went
pretty
smoothly. Development is underway, builds are being produced, life
is
good! :D

The sources for our currently shipping product are still in our
previous source code control system (ClearCase). We decided last
week to also migrate those sources to RTC, to make it easier to get
bugfixes for the current release into our next release. I know it
would have been easier to migrate the sources for the current
release
first, but hindsight is always 20/20.

Following is the procedure I followed. If there is a better way to
do
this please reply to this post.

To get the sources for our current release into RTC I created a new
stream for bugfixes of our current release and included many of the
components used by the up-coming release because they both share
many
java projects. In the new bugfix stream I set the component
baselines
to the Initial baseline. I then created a new Eclipse workspace,
connected to the repository and project, and created a new
repository
workspace which flowed to the bugfix stream. I then imported Java
projects from the current release into my Eclipse workspace. I
imported the projects from a copy of a snapshot view to make sure
ClearCase was not in the picture. I then attempted to share the
projects via Team->Share Project->Jazz Source Control. At
this
point a dialog was displayed stating the following

Component logview already has content in other sandboxes. This is
not
recommended and may result in components becoming out-of-sync when
you
deliver changes. Reason: There are several folders being shared to
a
component that is present in another sandbox.

The details section of the dialog contained the following.

Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models.hierarchy'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features\com.ibm.rational.test.lt.logviewer.feature'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\com.ibm.rational.test.lt.logviewer'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.hyades.statistical.ui'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'

If I continue on at this point and click OK to share the projects,
it
appeared to be processing the share of the projects for about 30
seconds to 1 min. Eventually though it returned a dialog
indicating
the share had failed with an internal error. Following is the
trace-back of the exception encountered.

An internal error occurred during: "Sharing Projects".

java.lang.IllegalArgumentException
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2453)
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2426)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.commitChanges(NewCheckInOperation.java:928)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.runRequest(NewCheckInOperation.java:772)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation$1.run(NewCheckInOperation.java:650)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:421)
at

org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:433)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:173)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:153)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.execute(NewCheckInOperation.java:675)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.filesystem.client.internal.share.ShareVersionables.commitNewProjectContents(ShareVersionables.java:176)
at

com.ibm.team.filesystem.client.internal.share.ShareOperation.execute(ShareOperation.java:564)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.internal.filesystem.ui.wizards.sharing.SharingWizard$2.filesystemRun(SharingWizard.java:317)
at

com.ibm.team.filesystem.ui.operations.FileSystemUIOperation.repositoryRun(FileSystemUIOperation.java:43)
at

com.ibm.team.repository.rcp.ui.operations.RepositoryOperation.run(RepositoryOperation.java:42)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner.run(JobRunner.java:205)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner$1.run(JobRunner.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

First, I'll re-iterate my disclaimer:

In general, there is no way to insert "previous history" into a release
or file.

Ok, with that said (:-),
approach one does not allow you to transfer bug fixes from the earlier
release to the current release. It just lets you have a configuration
of that earlier release in RTC.

The second approach allows you do transfer bug fixes (except for fixes
to renamed files, which will just be ignored ... so you really shouldn't
consider the second approach if you have renamed files between the two
releases). But if you do want to consider the second approach, a more
detailed description would be:

Let orig-comp-I be the original I'th RTC component
Let orig-stream be the original RTC stream
Let ws be an RTC workspace

- Create a new stream, prev-rel-new-stream.
- Create a new workspace, ws, on prev-rel-new-stream.
- Create new components, new-comp-I, in in ws.
- Import all the source from the previous release into the new-comp-I
components in ws.
- Deliver ws to prev-rel-new-stream.
- Create a new stream, cur-rel-new-stream.
- Deliver ws to cur-rel-new-stream.
- Delete all the source files in the ws sandbox, and add to the ws
sandbox all the source files from a sandbox associated with orig-stream.
- Deliver ws to cur-rel-new-stream.

Then prev-rel-new-stream is where you would do your work (patches) on
the previous release, and cur-rel-new-stream is where you would do your
work on the current release.

Cheers,
Geoff



tneal wrote:

Work item 95442 has been submitted. The reason we are trying to
import the previous version is in the hopes that we could then make
changes to the elements/files via the bugfix stream and then more
easily get those changes into sources for our next release. Instead
of having to do it manually by copying changes from our ClearCase
views.

Below you suggest that we create a new set of components (we have 33
components) to hold the file versions from the previous release. If
we did that, how do we get bug fixes from the current release into
the up-coming release? I don't understand how to make the changes
flow into the current set of components holding the sources for our
up-coming release.

If we take the second "come close" suggestion below,
wouldn't the contents of the components be the merging of the current
release code and the up-coming release code? That is great for work
going forward in the up-coming release. But we still need to create
builds that do not contain any of the up-coming code, just the
bugfixes for the current release. ie. two streams/branches of the
elements. Maybe I don't correctly understand how patches work in
RTC.

Maybe we will just have to continue to use CC for bugfixes of the
current release and use RTC for future releases.

Thanks!

--tom

gmclemmwrote:
Any "internal error" should be submitted as a work item.
Please file it
as a Defect against the "Source Control" category.

WRT what you were trying to do, a key question is what you were
trying
to achieve by importing the earlier release. The simplest way to do
the
import (that would avoid the bug you encountered) would be to just
import the earlier release into a new component.

In general, there is no way to insert "previous history"
into a release
or file. For one thing, since files can get renamed, there's no
generally reliable way to "match up" files from two
different releases.
But if you wanted to come "close" (i.e. treat file moves
as just
add/delete changes, as CVS would :-) ), and if you didn't care about

carrying forward the change-set history from your current RTC work,
you
could:
- import the old release into a new component in a new stream
- have all developers deliver all their work to the current release
- replace all the files in the old release sandbox with the current

files in the current release
- deliver the result to the new component.
- have all your developers switch their workspaces to the new stream

(with the new component).

The new stream wouldn't have the intermediate history of the new
development (you'd have to go to the old stream for that), but it
would
have the old release and the new release (and you could for example,

start doing patches to the old release in RTC, and merge them
forward to
the new release).

Cheers,
Geoff

tneal wrote:
Our development group has recently migrated to RTC 2.0 for project
mgmt and control of our source code. About a month ago I migrated
the sources for our up-coming release into RTC and things went
pretty
smoothly. Development is underway, builds are being produced, life
is
good! :D

The sources for our currently shipping product are still in our
previous source code control system (ClearCase). We decided last
week to also migrate those sources to RTC, to make it easier to get
bugfixes for the current release into our next release. I know it
would have been easier to migrate the sources for the current
release
first, but hindsight is always 20/20.

Following is the procedure I followed. If there is a better way to
do
this please reply to this post.

To get the sources for our current release into RTC I created a new
stream for bugfixes of our current release and included many of the
components used by the up-coming release because they both share
many
java projects. In the new bugfix stream I set the component
baselines
to the Initial baseline. I then created a new Eclipse workspace,
connected to the repository and project, and created a new
repository
workspace which flowed to the bugfix stream. I then imported Java
projects from the current release into my Eclipse workspace. I
imported the projects from a copy of a snapshot view to make sure
ClearCase was not in the picture. I then attempted to share the
projects via Team->Share Project->Jazz Source Control. At
this
point a dialog was displayed stating the following

Component logview already has content in other sandboxes. This is
not
recommended and may result in components becoming out-of-sync when
you
deliver changes. Reason: There are several folders being shared to
a
component that is present in another sandbox.

The details section of the dialog contained the following.

Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models.hierarchy'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features\com.ibm.rational.test.lt.logviewer.feature'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\com.ibm.rational.test.lt.logviewer'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.hyades.statistical.ui'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'

If I continue on at this point and click OK to share the projects,
it
appeared to be processing the share of the projects for about 30
seconds to 1 min. Eventually though it returned a dialog
indicating
the share had failed with an internal error. Following is the
trace-back of the exception encountered.

An internal error occurred during: "Sharing Projects".

java.lang.IllegalArgumentException
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2453)
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2426)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.commitChanges(NewCheckInOperation.java:928)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.runRequest(NewCheckInOperation.java:772)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation$1.run(NewCheckInOperation.java:650)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:421)
at

org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:433)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:173)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:153)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.execute(NewCheckInOperation.java:675)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.filesystem.client.internal.share.ShareVersionables.commitNewProjectContents(ShareVersionables.java:176)
at

com.ibm.team.filesystem.client.internal.share.ShareOperation.execute(ShareOperation.java:564)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.internal.filesystem.ui.wizards.sharing.SharingWizard$2.filesystemRun(SharingWizard.java:317)
at

com.ibm.team.filesystem.ui.operations.FileSystemUIOperation.repositoryRun(FileSystemUIOperation.java:43)
at

com.ibm.team.repository.rcp.ui.operations.RepositoryOperation.run(RepositoryOperation.java:42)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner.run(JobRunner.java:205)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner$1.run(JobRunner.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Thanks Geoff, disclaimer noted. 8-)

The breakdown of the steps for the second suggestion does help make things clearer. I'll have to verify if we had any/many filename changes between the two releases. If none, the hardest part will be to figure out which is more work in the long run. Stay with ClearCase while we support one final fixpack and manually merge bugfixes to the up-coming release, or shuffling the RTC components and streams and moving all the developers over to the new streams.

Thanks again for your help!

--tom

First, I'll re-iterate my disclaimer:

In general, there is no way to insert "previous history" into a release
or file.

Ok, with that said (:-),
approach one does not allow you to transfer bug fixes from the earlier
release to the current release. It just lets you have a configuration
of that earlier release in RTC.

The second approach allows you do transfer bug fixes (except for fixes
to renamed files, which will just be ignored ... so you really shouldn't
consider the second approach if you have renamed files between the two
releases). But if you do want to consider the second approach, a more
detailed description would be:

Let orig-comp-I be the original I'th RTC component
Let orig-stream be the original RTC stream
Let ws be an RTC workspace

- Create a new stream, prev-rel-new-stream.
- Create a new workspace, ws, on prev-rel-new-stream.
- Create new components, new-comp-I, in in ws.
- Import all the source from the previous release into the new-comp-I
components in ws.
- Deliver ws to prev-rel-new-stream.
- Create a new stream, cur-rel-new-stream.
- Deliver ws to cur-rel-new-stream.
- Delete all the source files in the ws sandbox, and add to the ws
sandbox all the source files from a sandbox associated with orig-stream.
- Deliver ws to cur-rel-new-stream.

Then prev-rel-new-stream is where you would do your work (patches) on
the previous release, and cur-rel-new-stream is where you would do your
work on the current release.

Cheers,
Geoff



tneal wrote:

Work item 95442 has been submitted. The reason we are trying to
import the previous version is in the hopes that we could then make
changes to the elements/files via the bugfix stream and then more
easily get those changes into sources for our next release. Instead
of having to do it manually by copying changes from our ClearCase
views.

Below you suggest that we create a new set of components (we have 33
components) to hold the file versions from the previous release. If
we did that, how do we get bug fixes from the current release into
the up-coming release? I don't understand how to make the changes
flow into the current set of components holding the sources for our
up-coming release.

If we take the second "come close" suggestion below,
wouldn't the contents of the components be the merging of the current
release code and the up-coming release code? That is great for work
going forward in the up-coming release. But we still need to create
builds that do not contain any of the up-coming code, just the
bugfixes for the current release. ie. two streams/branches of the
elements. Maybe I don't correctly understand how patches work in
RTC.

Maybe we will just have to continue to use CC for bugfixes of the
current release and use RTC for future releases.

Thanks!

--tom

gmclemmwrote:
Any "internal error" should be submitted as a work item.
Please file it
as a Defect against the "Source Control" category.

WRT what you were trying to do, a key question is what you were
trying
to achieve by importing the earlier release. The simplest way to do
the
import (that would avoid the bug you encountered) would be to just
import the earlier release into a new component.

In general, there is no way to insert "previous history"
into a release
or file. For one thing, since files can get renamed, there's no
generally reliable way to "match up" files from two
different releases.
But if you wanted to come "close" (i.e. treat file moves
as just
add/delete changes, as CVS would :-) ), and if you didn't care about

carrying forward the change-set history from your current RTC work,
you
could:
- import the old release into a new component in a new stream
- have all developers deliver all their work to the current release
- replace all the files in the old release sandbox with the current

files in the current release
- deliver the result to the new component.
- have all your developers switch their workspaces to the new stream

(with the new component).

The new stream wouldn't have the intermediate history of the new
development (you'd have to go to the old stream for that), but it
would
have the old release and the new release (and you could for example,

start doing patches to the old release in RTC, and merge them
forward to
the new release).

Cheers,
Geoff

tneal wrote:
Our development group has recently migrated to RTC 2.0 for project
mgmt and control of our source code. About a month ago I migrated
the sources for our up-coming release into RTC and things went
pretty
smoothly. Development is underway, builds are being produced, life
is
good! :D

The sources for our currently shipping product are still in our
previous source code control system (ClearCase). We decided last
week to also migrate those sources to RTC, to make it easier to get
bugfixes for the current release into our next release. I know it
would have been easier to migrate the sources for the current
release
first, but hindsight is always 20/20.

Following is the procedure I followed. If there is a better way to
do
this please reply to this post.

To get the sources for our current release into RTC I created a new
stream for bugfixes of our current release and included many of the
components used by the up-coming release because they both share
many
java projects. In the new bugfix stream I set the component
baselines
to the Initial baseline. I then created a new Eclipse workspace,
connected to the repository and project, and created a new
repository
workspace which flowed to the bugfix stream. I then imported Java
projects from the current release into my Eclipse workspace. I
imported the projects from a copy of a snapshot view to make sure
ClearCase was not in the picture. I then attempted to share the
projects via Team->Share Project->Jazz Source Control. At
this
point a dialog was displayed stating the following

Component logview already has content in other sandboxes. This is
not
recommended and may result in components becoming out-of-sync when
you
deliver changes. Reason: There are several folders being shared to
a
component that is present in another sandbox.

The details section of the dialog contained the following.

Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models.hierarchy'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features\com.ibm.rational.test.lt.logviewer.feature'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\com.ibm.rational.test.lt.logviewer'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.hyades.statistical.ui'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'

If I continue on at this point and click OK to share the projects,
it
appeared to be processing the share of the projects for about 30
seconds to 1 min. Eventually though it returned a dialog
indicating
the share had failed with an internal error. Following is the
trace-back of the exception encountered.

An internal error occurred during: "Sharing Projects".

java.lang.IllegalArgumentException
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2453)
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2426)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.commitChanges(NewCheckInOperation.java:928)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.runRequest(NewCheckInOperation.java:772)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation$1.run(NewCheckInOperation.java:650)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:421)
at

org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:433)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:173)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:153)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.execute(NewCheckInOperation.java:675)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.filesystem.client.internal.share.ShareVersionables.commitNewProjectContents(ShareVersionables.java:176)
at

com.ibm.team.filesystem.client.internal.share.ShareOperation.execute(ShareOperation.java:564)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.internal.filesystem.ui.wizards.sharing.SharingWizard$2.filesystemRun(SharingWizard.java:317)
at

com.ibm.team.filesystem.ui.operations.FileSystemUIOperation.repositoryRun(FileSystemUIOperation.java:43)
at

com.ibm.team.repository.rcp.ui.operations.RepositoryOperation.run(RepositoryOperation.java:42)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner.run(JobRunner.java:205)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner$1.run(JobRunner.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

There is third way to address this. As said, there is no way to insert previous history. But you can go back in time and split stream. This is another option, but beware that the history of your old release may look a little strange.

This way does not require creating any new components. It does allow you to try and flow changes between the streams for the old release and the current release. The history of the old release may appear a little odd depending upon when you started the current release in RTC.

current_release is the stream that is currently on the go within RTC.
old_release is the stream for the release that is currently in CC that you want to move to RTC.
ws is a workspace that you are going to do all the work with.

create ws by adding all the components from current_stream. If possible, seed the workspace with baselines that are close to when you first started current_stream as those file versions will likely be closer to what was there in CC right now. In the workspace editor you should be able to search for baselines for each of the components. DO NOT load ws.

Start with a clean eclipse workspace and import all the projects that represent old_release in CC. Select the projects and share them with the appropriate component in ws. I would recommend doing it 1 project at a time until you get the hang of it. When you share the project and are presented with the components, select the parent directory that will hold "foo", or the component if it is directly under the component (NOT the folder "foo" itself within the component). If you make a mistake and want to discard changes, select the projects affected in the package explorer and "Team > Disconnect" the project first. Then undo the changes and try again.

When the share (really a reshare) is done, you should have some pending changes. The pending change will reflect a reverse of the changes made to the item in current_release and any other changes that were made to old_release that were not made to current_release. You should not see a whole tree automatically checked in unless the project is nolonger in current_release (if you do see it, you may not have picked the right thing to share against).

Check those changes in.

Take a look at the repostiory files view for each component in ws. Make sure that there are no projects in ws that are not in your Eclipse workspace (these would be new projects that were added during development to current_release that are not in old_release).

Label the changesets to explain that they are reversal for initial setup. Create a snapshot for ws. Create a stream old_release seeded with this snapshot.

Now your developers can create a old_ws that collaborates with old_release and make changes and deliver the fixes for the fixpack. They also have a current_ws that collaborates with current_release. If they wish to pull changes from old_release to the current release in progress, they can change current_ws to collaborate with old_release and accept the changes. They may have conflicts that have to be resolved if the files affected have moved forward in the development of the current release. If the files in the changeset have been involved in changesets in old_release that have not been brought forward (i.e. the reversal-setup changeset or other changes) they will be told that there is a gap and asked if they want to accept the changes as a patch. They can answer yes and then merge the patches in. Then change the collaboration of current_ws back to current_release and deliver. Similarily you can pull changes from the current_release and push them to old_release by using the old_ws to collaborate with accept the relevant changesets from current_release.

To minimize the number of gaps hit, you want to seed ws with a baseline/configuration as close as possible to what is in CC.

- Heather

Thanks Geoff, disclaimer noted. 8-)

The breakdown of the steps for the second suggestion does help make things clearer. I'll have to verify if we had any/many filename changes between the two releases. If none, the hardest part will be to figure out which is more work in the long run. Stay with ClearCase while we support one final fixpack and manually merge bugfixes to the up-coming release, or shuffling the RTC components and streams and moving all the developers over to the new streams.

Thanks again for your help!

--tom

First, I'll re-iterate my disclaimer:

In general, there is no way to insert "previous history" into a release
or file.

Ok, with that said (:-),
approach one does not allow you to transfer bug fixes from the earlier
release to the current release. It just lets you have a configuration
of that earlier release in RTC.

The second approach allows you do transfer bug fixes (except for fixes
to renamed files, which will just be ignored ... so you really shouldn't
consider the second approach if you have renamed files between the two
releases). But if you do want to consider the second approach, a more
detailed description would be:

Let orig-comp-I be the original I'th RTC component
Let orig-stream be the original RTC stream
Let ws be an RTC workspace

- Create a new stream, prev-rel-new-stream.
- Create a new workspace, ws, on prev-rel-new-stream.
- Create new components, new-comp-I, in in ws.
- Import all the source from the previous release into the new-comp-I
components in ws.
- Deliver ws to prev-rel-new-stream.
- Create a new stream, cur-rel-new-stream.
- Deliver ws to cur-rel-new-stream.
- Delete all the source files in the ws sandbox, and add to the ws
sandbox all the source files from a sandbox associated with orig-stream.
- Deliver ws to cur-rel-new-stream.

Then prev-rel-new-stream is where you would do your work (patches) on
the previous release, and cur-rel-new-stream is where you would do your
work on the current release.

Cheers,
Geoff



tneal wrote:

Work item 95442 has been submitted. The reason we are trying to
import the previous version is in the hopes that we could then make
changes to the elements/files via the bugfix stream and then more
easily get those changes into sources for our next release. Instead
of having to do it manually by copying changes from our ClearCase
views.

Below you suggest that we create a new set of components (we have 33
components) to hold the file versions from the previous release. If
we did that, how do we get bug fixes from the current release into
the up-coming release? I don't understand how to make the changes
flow into the current set of components holding the sources for our
up-coming release.

If we take the second "come close" suggestion below,
wouldn't the contents of the components be the merging of the current
release code and the up-coming release code? That is great for work
going forward in the up-coming release. But we still need to create
builds that do not contain any of the up-coming code, just the
bugfixes for the current release. ie. two streams/branches of the
elements. Maybe I don't correctly understand how patches work in
RTC.

Maybe we will just have to continue to use CC for bugfixes of the
current release and use RTC for future releases.

Thanks!

--tom

gmclemmwrote:
Any "internal error" should be submitted as a work item.
Please file it
as a Defect against the "Source Control" category.

WRT what you were trying to do, a key question is what you were
trying
to achieve by importing the earlier release. The simplest way to do
the
import (that would avoid the bug you encountered) would be to just
import the earlier release into a new component.

In general, there is no way to insert "previous history"
into a release
or file. For one thing, since files can get renamed, there's no
generally reliable way to "match up" files from two
different releases.
But if you wanted to come "close" (i.e. treat file moves
as just
add/delete changes, as CVS would :-) ), and if you didn't care about

carrying forward the change-set history from your current RTC work,
you
could:
- import the old release into a new component in a new stream
- have all developers deliver all their work to the current release
- replace all the files in the old release sandbox with the current

files in the current release
- deliver the result to the new component.
- have all your developers switch their workspaces to the new stream

(with the new component).

The new stream wouldn't have the intermediate history of the new
development (you'd have to go to the old stream for that), but it
would
have the old release and the new release (and you could for example,

start doing patches to the old release in RTC, and merge them
forward to
the new release).

Cheers,
Geoff

tneal wrote:
Our development group has recently migrated to RTC 2.0 for project
mgmt and control of our source code. About a month ago I migrated
the sources for our up-coming release into RTC and things went
pretty
smoothly. Development is underway, builds are being produced, life
is
good! :D

The sources for our currently shipping product are still in our
previous source code control system (ClearCase). We decided last
week to also migrate those sources to RTC, to make it easier to get
bugfixes for the current release into our next release. I know it
would have been easier to migrate the sources for the current
release
first, but hindsight is always 20/20.

Following is the procedure I followed. If there is a better way to
do
this please reply to this post.

To get the sources for our current release into RTC I created a new
stream for bugfixes of our current release and included many of the
components used by the up-coming release because they both share
many
java projects. In the new bugfix stream I set the component
baselines
to the Initial baseline. I then created a new Eclipse workspace,
connected to the repository and project, and created a new
repository
workspace which flowed to the bugfix stream. I then imported Java
projects from the current release into my Eclipse workspace. I
imported the projects from a copy of a snapshot view to make sure
ClearCase was not in the picture. I then attempted to share the
projects via Team->Share Project->Jazz Source Control. At
this
point a dialog was displayed stating the following

Component logview already has content in other sandboxes. This is
not
recommended and may result in components becoming out-of-sync when
you
deliver changes. Reason: There are several folders being shared to
a
component that is present in another sandbox.

The details section of the dialog contained the following.

Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models.hierarchy'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features\com.ibm.rational.test.lt.logviewer.feature'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\com.ibm.rational.test.lt.logviewer'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder

'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.hyades.statistical.ui'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'

If I continue on at this point and click OK to share the projects,
it
appeared to be processing the share of the projects for about 30
seconds to 1 min. Eventually though it returned a dialog
indicating
the share had failed with an internal error. Following is the
trace-back of the exception encountered.

An internal error occurred during: "Sharing Projects".

java.lang.IllegalArgumentException
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2453)
at

com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2426)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.commitChanges(NewCheckInOperation.java:928)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.runRequest(NewCheckInOperation.java:772)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation$1.run(NewCheckInOperation.java:650)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:421)
at

org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at

com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:433)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:173)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:153)
at

com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.execute(NewCheckInOperation.java:675)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.filesystem.client.internal.share.ShareVersionables.commitNewProjectContents(ShareVersionables.java:176)
at

com.ibm.team.filesystem.client.internal.share.ShareOperation.execute(ShareOperation.java:564)
at

com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at

com.ibm.team.internal.filesystem.ui.wizards.sharing.SharingWizard$2.filesystemRun(SharingWizard.java:317)
at

com.ibm.team.filesystem.ui.operations.FileSystemUIOperation.repositoryRun(FileSystemUIOperation.java:43)
at

com.ibm.team.repository.rcp.ui.operations.RepositoryOperation.run(RepositoryOperation.java:42)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner.run(JobRunner.java:205)
at

com.ibm.team.repository.rcp.ui.operations.JobRunner$1.run(JobRunner.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Wahoo! It looks like your suggestion has allowed me to get the
sources for our fixpack release into RTC without having to create new
components! I still have some verification to do and I haven't tried
to flow the fixpack release stream into the up-coming release stream
but initial checks look good. Thanks very much for your help!

--tom

heatherfwrote:
There is third way to address this. As said, there is no way to
insert previous history. But you can go back in time and split
stream. This is another option, but beware that the history of your
old release may look a little strange.
This way does not require creating any new components. It does
allow you to try and flow changes between the streams for the old
release and the current release. The history of the old release may
appear a little odd depending upon when you started the current
release in RTC.
current_release is the stream that is currently on the go within
RTC.
old_release is the stream for the release that is currently in CC
that you want to move to RTC.
ws is a workspace that you are going to do all the work with.

create ws by adding all the components from current_stream. If
possible, seed the workspace with baselines that are close to when
you first started current_stream as those file versions will likely
be closer to what was there in CC right now. In the workspace editor
you should be able to search for baselines for each of the components.
DO NOT load ws.
Start with a clean eclipse workspace and import all the projects
that represent old_release in CC. Select the projects and share them
with the appropriate component in ws. I would recommend doing it 1
project at a time until you get the hang of it. When you share the
project and are presented with the components, select the parent
directory that will hold "foo", or the component if it is
directly under the component (NOT the folder "foo" itself
within the component). If you make a mistake and want to discard
changes, select the projects affected in the package explorer and
"Team > Disconnect" the project first. Then undo the
changes and try again.
When the share (really a reshare) is done, you should have some
pending changes. The pending change will reflect a reverse of the
changes made to the item in current_release and any other changes
that were made to old_release that were not made to current_release.
You should not see a whole tree automatically checked in unless the
project is nolonger in current_release (if you do see it, you may not
have picked the right thing to share against).
Check those changes in.

Take a look at the repostiory files view for each component in ws.
Make sure that there are no projects in ws that are not in your
Eclipse workspace (these would be new projects that were added during
development to current_release that are not in old_release).
Label the changesets to explain that they are reversal for initial
setup. Create a snapshot for ws. Create a stream old_release seeded
with this snapshot.
Now your developers can create a old_ws that collaborates with
old_release and make changes and deliver the fixes for the fixpack.
They also have a current_ws that collaborates with current_release.
If they wish to pull changes from old_release to the current release
in progress, they can change current_ws to collaborate with
old_release and accept the changes. They may have conflicts that
have to be resolved if the files affected have moved forward in the
development of the current release. If the files in the changeset
have been involved in changesets in old_release that have not been
brought forward (i.e. the reversal-setup changeset or other changes)
they will be told that there is a gap and asked if they want to
accept the changes as a patch. They can answer yes and then merge
the patches in. Then change the collaboration of current_ws back to
current_release and deliver. Similarily you can pull changes from
the current_release and push them to old_release by using the old_ws
to collaborate with accept the relevant changesets from
current_release.
To minimize the number of gaps hit, you want to seed ws with a
baseline/configuration as close as possible to what is in CC.
- Heather

tnealwrote:
Thanks Geoff, disclaimer noted. 8-)
The breakdown of the steps for the second suggestion does help make
things clearer. I'll have to verify if we had any/many filename
changes between the two releases. If none, the hardest part will be
to figure out which is more work in the long run. Stay with
ClearCase while we support one final fixpack and manually merge
bugfixes to the up-coming release, or shuffling the RTC components
and streams and moving all the developers over to the new streams.
Thanks again for your help!

--tom

gmclemmwrote:
First, I'll re-iterate my disclaimer:
In general, there is no way to insert "previous history"
into a release
or file.

Ok, with that said (:-),
approach one does not allow you to transfer bug fixes from the
earlier
release to the current release. It just lets you have a
configuration
of that earlier release in RTC.

The second approach allows you do transfer bug fixes (except for
fixes
to renamed files, which will just be ignored ... so you really
shouldn't
consider the second approach if you have renamed files between the
two
releases). But if you do want to consider the second approach, a
more
detailed description would be:

Let orig-comp-I be the original I'th RTC component
Let orig-stream be the original RTC stream
Let ws be an RTC workspace

- Create a new stream, prev-rel-new-stream.
- Create a new workspace, ws, on prev-rel-new-stream.
- Create new components, new-comp-I, in in ws.
- Import all the source from the previous release into the
new-comp-I
components in ws.
- Deliver ws to prev-rel-new-stream.
- Create a new stream, cur-rel-new-stream.
- Deliver ws to cur-rel-new-stream.
- Delete all the source files in the ws sandbox, and add to the ws
sandbox all the source files from a sandbox associated with
orig-stream.
- Deliver ws to cur-rel-new-stream.

Then prev-rel-new-stream is where you would do your work (patches)
on
the previous release, and cur-rel-new-stream is where you would do
your
work on the current release.

Cheers,
Geoff



tneal wrote:
Work item 95442 has been submitted. The reason we are trying to
import the previous version is in the hopes that we could then make
changes to the elements/files via the bugfix stream and then more
easily get those changes into sources for our next release.
Instead
of having to do it manually by copying changes from our ClearCase
views.

Below you suggest that we create a new set of components (we have
33
components) to hold the file versions from the previous release.
If
we did that, how do we get bug fixes from the current release into
the up-coming release? I don't understand how to make the changes
flow into the current set of components holding the sources for our
up-coming release.

If we take the second "come close" suggestion below,
wouldn't the contents of the components be the merging of the
current
release code and the up-coming release code? That is great for
work
going forward in the up-coming release. But we still need to
create
builds that do not contain any of the up-coming code, just the
bugfixes for the current release. ie. two streams/branches of the
elements. Maybe I don't correctly understand how patches work in
RTC.

Maybe we will just have to continue to use CC for bugfixes of the
current release and use RTC for future releases.

Thanks!

--tom

gmclemmwrote:
Any "internal error" should be submitted as a work item.
Please file it
as a Defect against the "Source Control" category.

WRT what you were trying to do, a key question is what you were
trying
to achieve by importing the earlier release. The simplest way to
do
the
import (that would avoid the bug you encountered) would be to just
import the earlier release into a new component.

In general, there is no way to insert "previous history"
into a release
or file. For one thing, since files can get renamed, there's no
generally reliable way to "match up" files from two
different releases.
But if you wanted to come "close" (i.e. treat file moves
as just
add/delete changes, as CVS would :-) ), and if you didn't care
about
carrying forward the change-set history from your current RTC work,
you
could:
- import the old release into a new component in a new stream
- have all developers deliver all their work to the current release
- replace all the files in the old release sandbox with the current

files in the current release
- deliver the result to the new component.
- have all your developers switch their workspaces to the new
stream
(with the new component).

The new stream wouldn't have the intermediate history of the new
development (you'd have to go to the old stream for that), but it
would
have the old release and the new release (and you could for
example,
start doing patches to the old release in RTC, and merge them
forward to
the new release).

Cheers,
Geoff

tneal wrote:
Our development group has recently migrated to RTC 2.0 for project
mgmt and control of our source code. About a month ago I migrated
the sources for our up-coming release into RTC and things went
pretty
smoothly. Development is underway, builds are being produced, life
is
good! :D

The sources for our currently shipping product are still in our
previous source code control system (ClearCase). We decided last
week to also migrate those sources to RTC, to make it easier to get
bugfixes for the current release into our next release. I know it
would have been easier to migrate the sources for the current
release
first, but hindsight is always 20/20.

Following is the procedure I followed. If there is a better way to
do
this please reply to this post.

To get the sources for our current release into RTC I created a new
stream for bugfixes of our current release and included many of the
components used by the up-coming release because they both share
many
java projects. In the new bugfix stream I set the component
baselines
to the Initial baseline. I then created a new Eclipse workspace,
connected to the repository and project, and created a new
repository
workspace which flowed to the bugfix stream. I then imported Java
projects from the current release into my Eclipse workspace. I
imported the projects from a copy of a snapshot view to make sure
ClearCase was not in the picture. I then attempted to share the
projects via Team->Share Project->Jazz Source Control. At
this
point a dialog was displayed stating the following

Component logview already has content in other sandboxes. This is
not
recommended and may result in components becoming out-of-sync when
you
deliver changes. Reason: There are several folders being shared
to
a
component that is present in another sandbox.

The details section of the dialog contained the following.

Folder


'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models.hierarchy'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder


'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features\com.ibm.rational.test.lt.logviewer.feature'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins'
Folder


'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\com.ibm.rational.test.lt.logviewer'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder


'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.tptp.platform.models'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'
Folder


'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\plugins\org.eclipse.hyades.statistical.ui'
is being shared into 'logview' which also has content in sandbox
'D:\tneal\snapshot_copy_8.1_FP\loadtest_mixedsrc\logview\features'

If I continue on at this point and click OK to share the projects,
it
appeared to be processing the share of the projects for about 30
seconds to 1 min. Eventually though it returned a dialog
indicating
the share had failed with an internal error. Following is the
trace-back of the exception encountered.

An internal error occurred during: "Sharing Projects".

java.lang.IllegalArgumentException
at


com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2453)
at


com.ibm.team.scm.client.internal.WorkspaceConnection.commit(WorkspaceConnection.java:2426)
at


com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.commitChanges(NewCheckInOperation.java:928)
at


com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.runRequest(NewCheckInOperation.java:772)
at


com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation$1.run(NewCheckInOperation.java:650)
at


com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:421)
at


org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at


com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:433)
at


com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:173)
at


com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:153)
at


com.ibm.team.filesystem.client.internal.operations.NewCheckInOperation.execute(NewCheckInOperation.java:675)
at


com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at


com.ibm.team.filesystem.client.internal.share.ShareVersionables.commitNewProjectContents(ShareVersionables.java:176)
at


com.ibm.team.filesystem.client.internal.share.ShareOperation.execute(ShareOperation.java:564)
at


com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:90)
at


com.ibm.team.internal.filesystem.ui.wizards.sharing.SharingWizard$2.filesystemRun(SharingWizard.java:317)
at


com.ibm.team.filesystem.ui.operations.FileSystemUIOperation.repositoryRun(FileSystemUIOperation.java:43)
at


com.ibm.team.repository.rcp.ui.operations.RepositoryOperation.run(RepositoryOperation.java:42)
at


com.ibm.team.repository.rcp.ui.operations.JobRunner.run(JobRunner.java:205)
at


com.ibm.team.repository.rcp.ui.operations.JobRunner$1.run(JobRunner.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)