It's all about the answers!

Ask a question

Exporting / Importing a project between servers


Peter Verdon (61232) | asked Jun 21 '11, 6:06 a.m.
A project is being transferred between teams and sites within our company. The old team developed the project in RTC 2, on a server at Site A. I am part of the new team, who will continue development at Site B. For various reasons, relating both to latency and control of our own destiny, we intend to move the project to a server here at Site B, and upgrade to RTC 3.0.1 at the same time.

Our IT department here at Site B provides a good hosting service for RTC. I've spoken to them, and they have asked for the administrators at Site A to export the project to a tar file (using something like "repo tool"?) and send it over. They will then handle the import and upgrade for us here. However, when I opened a ticket with the RTC admins at Site A, they raised the following objections:


IF this were considered...

    Exporting requires an outage affecting several development projects
    Experience has shown that an export of this size could take 10-15 hours.
    What assurances would be given that the data in all the projects *not* mentioned on this request would be made inaccessible to users in the potential new location
    The database is >8Gb and I would imagine that the export would be at or near that number


Our admins here at Site B only run one project per RTC instance (not sure exactly what the topology is, but I know they make extensive use of virtualisation) which gives them the flexibility to import and export projects at will. It sounds to my non-expert understanding like the setup at Site A is to run multiple projects on an RTC instance, which causes the difficulties listed above. I very much doubt that this small project has 8GB of content, for instance, so it appears that they can only export a whole bundle of projects together. Hence the widespread outage, and the concern about accessibility as they would be shipping us the code for projects unrelated to us.

I have no idea where to go from here. Is the mass export with its associated problems our only option? The subtext is that this might require some political (management) will to achieve. Can anyone suggest an alternative approach I could pass on to the Site A admins which would allow them to extract only the content for our project? Any other ideas?

Cheers,

Pete

8 answers



permanent link
Peter Verdon (61232) | answered Jun 21 '11, 1:03 p.m.
A suggestion has been passed to me that it may be possible to set up an empty project here and then somehow "link" it with the old one before "pulling" components across. I've not come across the concept of linking projects before - does this sound remotely plausible?

Pete

permanent link
Geoffrey Clemm (30.1k33035) | answered Jun 22 '11, 1:54 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You cannot currently extract just a single project area from a
repository containing multiple project areas (but it is a high priority
enhancement for many customers: see work item 93151).

So your only approach today is to copy the entire repository to another
server, and then "read protect" all of the other project areas so that
nobody can read them (this read protection is secure and reliable).

NOTE: Unless you can use the original repository URL at the new server,
you should do the repository copy *before* upgrading from 2.0 to 3.0,
because in 3.0, modifying the repository URL is no longer supported (but
is another high priority enhancement: see work item 119503).

Cheers,
Geoff


On 6/21/2011 6:08 AM, peteverdon wrote:
A project is being transferred between teams and sites within our
company. The old team developed the project in RTC 2, on a server at
Site A. I am part of the new team, who will continue development at
Site B. For various reasons, relating both to latency and control of
our own destiny, we intend to move the project to a server here at
Site B, and upgrade to RTC 3.0.1 at the same time.

Our IT department here at Site B provides a good hosting service for
RTC. I've spoken to them, and they have asked for the administrators
at Site A to export the project to a tar file (using something like
"repo tool"?) and send it over. They will then handle the
import and upgrade for us here. However, when I opened a ticket with
the RTC admins at Site A, they raised the following objections:


IF this were considered...

Exporting requires an outage affecting several development projects
Experience has shown that an export of this size could take 10-15
hours.
What assurances would be given that the data in all the projects
*not* mentioned on this request would be made inaccessible to users
in the potential new location
The database is>8Gb and I would imagine that the export would be
at or near that number


Our admins here at Site B only run one project per RTC instance (not
sure exactly what the topology is, but I know they make extensive use
of virtualisation) which gives them the flexibility to import and
export projects at will. It sounds to my non-expert understanding
like the setup at Site A is to run multiple projects on an RTC
instance, which causes the difficulties listed above. I very much
doubt that this small project has 8GB of content, for instance, so it
appears that they can only export a whole bundle of projects together.
Hence the widespread outage, and the concern about accessibility as
they would be shipping us the code for projects unrelated to us.

I have no idea where to go from here. Is the mass export with its
associated problems our only option? The subtext is that this might
require some political (management) will to achieve. Can anyone
suggest an alternative approach I could pass on to the Site A admins
which would allow them to extract only the content for our project?
Any other ideas?

Cheers,

Pete

permanent link
Geoffrey Clemm (30.1k33035) | answered Jun 22 '11, 1:56 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The suggestion is a bit too vague, but if I had to guess, I'd guess that
they are referring to cross-repository work item linking (which is
supported). But that still requires that you keep the old server up
and running, rather than having the project hosted on the new server, so
I don't see that this would address your request.

Cheers,
Geoff

On 6/21/2011 1:08 PM, peteverdon wrote:
A suggestion has been passed to me that it may be possible to set up
an empty project here and then somehow "link" it with the
old one before "pulling" components across. I've not come
across the concept of linking projects before - does this sound
remotely plausible?

Pete

permanent link
Peter Verdon (61232) | answered Jun 22 '11, 5:19 a.m.
Yep, I had a look at the Infocenter after posting the "linking" suggestion and realised it wasn't relevant.

So it sounds like you're saying we're out of luck, and there is no way to extract our project without persuading the other site to take downtime on their other projects?

Our Architect is suggesting we simply load the code from the old server, disconnect, and then deliver it into an empty new server. I don't really like this plan as it (presumably) involves losing all history, work item associations, etc etc from the past work. Am I right?

Pete

permanent link
Geoffrey Clemm (30.1k33035) | answered Jun 22 '11, 6:17 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You shouldn't need much/any downtime on the other site.
Just restore a copy of your 2.0 repository to the new location, and then
mark all of the other project areas as unreadable by everyone (and mark
the "moved" project area as unreadable in the original repository).

Cheers,
Geoff

On 6/22/2011 5:23 AM, peteverdon wrote:
Yep, I had a look at the Infocenter after posting the
"linking" suggestion and realised it wasn't relevant.

So it sounds like you're saying we're out of luck, and there is no way
to extract our project without persuading the other site to take
downtime on their other projects?

Our Architect is suggesting we simply load the code from the old
server, disconnect, and then deliver it into an empty new server. I
don't really like this plan as it (presumably) involves losing all
history, work item associations, etc etc from the past work. Am I
right?

Pete

permanent link
Michael Haas (6) | answered Jul 04 '11, 6:46 p.m.
Hopefully it's not true that these two work items are high priority since one is open for 2 years the other for 1 year.
If it's true, how long would it take for low priority work item to get fixed ;)

You cannot currently extract just a single project area from a
repository containing multiple project areas (but it is a high priority
enhancement for many customers: see work item 93151).

So your only approach today is to copy the entire repository to another
server, and then "read protect" all of the other project areas so that
nobody can read them (this read protection is secure and reliable).

NOTE: Unless you can use the original repository URL at the new server,
you should do the repository copy *before* upgrading from 2.0 to 3.0,
because in 3.0, modifying the repository URL is no longer supported (but
is another high priority enhancement: see work item 119503).

Cheers,
Geoff


On 6/21/2011 6:08 AM, peteverdon wrote:
A project is being transferred between teams and sites within our
company. The old team developed the project in RTC 2, on a server at
Site A. I am part of the new team, who will continue development at
Site B. For various reasons, relating both to latency and control of
our own destiny, we intend to move the project to a server here at
Site B, and upgrade to RTC 3.0.1 at the same time.

Our IT department here at Site B provides a good hosting service for
RTC. I've spoken to them, and they have asked for the administrators
at Site A to export the project to a tar file (using something like
"repo tool"?) and send it over. They will then handle the
import and upgrade for us here. However, when I opened a ticket with
the RTC admins at Site A, they raised the following objections:


IF this were considered...

Exporting requires an outage affecting several development projects
Experience has shown that an export of this size could take 10-15
hours.
What assurances would be given that the data in all the projects
*not* mentioned on this request would be made inaccessible to users
in the potential new location
The database is>8Gb and I would imagine that the export would be
at or near that number


Our admins here at Site B only run one project per RTC instance (not
sure exactly what the topology is, but I know they make extensive use
of virtualisation) which gives them the flexibility to import and
export projects at will. It sounds to my non-expert understanding
like the setup at Site A is to run multiple projects on an RTC
instance, which causes the difficulties listed above. I very much
doubt that this small project has 8GB of content, for instance, so it
appears that they can only export a whole bundle of projects together.
Hence the widespread outage, and the concern about accessibility as
they would be shipping us the code for projects unrelated to us.

I have no idea where to go from here. Is the mass export with its
associated problems our only option? The subtext is that this might
require some political (management) will to achieve. Can anyone
suggest an alternative approach I could pass on to the Site A admins
which would allow them to extract only the content for our project?
Any other ideas?

Cheers,

Pete

permanent link
Geoffrey Clemm (30.1k33035) | answered Jul 05 '11, 8:16 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Some work items have their priority raised over time (as their
importance is recognized by a broader group of people), and some work
items take several releases (years) to implement. There was some
internal debate over whether 93151 was required, which has now been
resolved in its favor (from a planning perspective), but the work still
needs to be done.

But back to your particular problem, yes, your admins on site B are
doing the right thing to avoid the problem you are encountering with
moving a project area from site A (i.e. if site A used the same
approach, you would have a "repository move" scenario, rather than a
"repository partial move" scenario).

Your easiest approach for now would probably be to just bring the
appropriate subset of the code forward from site A to site B (using
cross-repository deliver, if you want to carry the history forward), and
not try to bring over the work items (you can either create new
instances of the top level work items, our use export/import to bring
over copies of the key work items).

Cheers,
Geoff

On 7/4/2011 6:53 PM, haasm wrote:
Hopefully it's not true that these two work items are high priority
since one is open for 2 years the other for 1 year.
If it's true, how long would it take for low priority work item to get
fixed ;)

gmclemmwrote:
You cannot currently extract just a single project area from a
repository containing multiple project areas (but it is a high
priority
enhancement for many customers: see work item 93151).

So your only approach today is to copy the entire repository to
another
server, and then "read protect" all of the other project
areas so that
nobody can read them (this read protection is secure and reliable).

NOTE: Unless you can use the original repository URL at the new
server,
you should do the repository copy *before* upgrading from 2.0 to
3.0,
because in 3.0, modifying the repository URL is no longer supported
(but
is another high priority enhancement: see work item 119503).

Cheers,
Geoff


On 6/21/2011 6:08 AM, peteverdon wrote:
A project is being transferred between teams and sites within our
company. The old team developed the project in RTC 2, on a server
at
Site A. I am part of the new team, who will continue development at
Site B. For various reasons, relating both to latency and control
of
our own destiny, we intend to move the project to a server here at
Site B, and upgrade to RTC 3.0.1 at the same time.

Our IT department here at Site B provides a good hosting service
for
RTC. I've spoken to them, and they have asked for the
administrators
at Site A to export the project to a tar file (using something like
"repo tool"?) and send it over. They will then handle the
import and upgrade for us here. However, when I opened a ticket
with
the RTC admins at Site A, they raised the following objections:


IF this were considered...

Exporting requires an outage affecting several development projects
Experience has shown that an export of this size could take 10-15
hours.
What assurances would be given that the data in all the projects
*not* mentioned on this request would be made inaccessible to users
in the potential new location
The database is>8Gb and I would imagine that the export would be
at or near that number

Our admins here at Site B only run one project per RTC instance (not
sure exactly what the topology is, but I know they make extensive use
of virtualisation) which gives them the flexibility to import and
export projects at will. It sounds to my non-expert understanding
like the setup at Site A is to run multiple projects on an RTC
instance, which causes the difficulties listed above. I very much
doubt that this small project has 8GB of content, for instance, so it
appears that they can only export a whole bundle of projects
together.
Hence the widespread outage, and the concern about accessibility as
they would be shipping us the code for projects unrelated to us.

I have no idea where to go from here. Is the mass export with its
associated problems our only option? The subtext is that this might
require some political (management) will to achieve. Can anyone
suggest an alternative approach I could pass on to the Site A admins
which would allow them to extract only the content for our project?
Any other ideas?

Cheers,

Pete


permanent link
Dave Marsico (4511014) | answered Jul 15 '11, 5:23 p.m.
We are investigating the cross-repository project move as well
This article did provide some excellent guidance
https://jazz.net/library/article/535

In Testing it was pretty straightforward to pull component across to a new server, and you can do some iterative delivers to avoid a big bang experience.
We also looking at the work item issue as our source repository server will decommision. So looking to either export/import the key ones and just recreate/populate work items based on the originals, appears you can remove the "carried" over reference to the work items on the source server. Hoping to have very little to nothing dangling, but thats a question I suppose, what else might be there to consider?

Here's my outline to date:
o) use cross-repository deliver move component content from 1 server to another
o) workitem fixup
- either flatfile export workitems from source project and then import in target project or
- manually create and link new work items the appropriate changesets (in both cases, using the existing work item as guide)
- removing references to work items in the source server from the change sets in the target server component
o) manually create any snapshots if required
o) turn off the replicate change set permissions? (when is safe to do this??)
o) remove the Associations between the Projects/Artifacts? (are the components officially decoupled at this point??)
o) defriend the servers
o) disable the Distributed SCM
o) decom source server (a month later perhaps)

are these sensible steps, anything left out, or that we need to watch out for?

Just Wondering out loud if there are any other linkages that may be under the covers.

Appreciate any comments

Dave

Some work items have their priority raised over time (as their
importance is recognized by a broader group of people), and some work
items take several releases (years) to implement. There was some
internal debate over whether 93151 was required, which has now been
resolved in its favor (from a planning perspective), but the work still
needs to be done.

But back to your particular problem, yes, your admins on site B are
doing the right thing to avoid the problem you are encountering with
moving a project area from site A (i.e. if site A used the same
approach, you would have a "repository move" scenario, rather than a
"repository partial move" scenario).

Your easiest approach for now would probably be to just bring the
appropriate subset of the code forward from site A to site B (using
cross-repository deliver, if you want to carry the history forward), and
not try to bring over the work items (you can either create new
instances of the top level work items, our use export/import to bring
over copies of the key work items).

Cheers,
Geoff

On 7/4/2011 6:53 PM, haasm wrote:
Hopefully it's not true that these two work items are high priority
since one is open for 2 years the other for 1 year.
If it's true, how long would it take for low priority work item to get
fixed ;)

gmclemmwrote:
You cannot currently extract just a single project area from a
repository containing multiple project areas (but it is a high
priority
enhancement for many customers: see work item 93151).

So your only approach today is to copy the entire repository to
another
server, and then "read protect" all of the other project
areas so that
nobody can read them (this read protection is secure and reliable).

NOTE: Unless you can use the original repository URL at the new
server,
you should do the repository copy *before* upgrading from 2.0 to
3.0,
because in 3.0, modifying the repository URL is no longer supported
(but
is another high priority enhancement: see work item 119503).

Cheers,
Geoff


On 6/21/2011 6:08 AM, peteverdon wrote:
A project is being transferred between teams and sites within our
company. The old team developed the project in RTC 2, on a server
at
Site A. I am part of the new team, who will continue development at
Site B. For various reasons, relating both to latency and control
of
our own destiny, we intend to move the project to a server here at
Site B, and upgrade to RTC 3.0.1 at the same time.

Our IT department here at Site B provides a good hosting service
for
RTC. I've spoken to them, and they have asked for the
administrators
at Site A to export the project to a tar file (using something like
"repo tool"?) and send it over. They will then handle the
import and upgrade for us here. However, when I opened a ticket
with
the RTC admins at Site A, they raised the following objections:


IF this were considered...

Exporting requires an outage affecting several development projects
Experience has shown that an export of this size could take 10-15
hours.
What assurances would be given that the data in all the projects
*not* mentioned on this request would be made inaccessible to users
in the potential new location
The database is>8Gb and I would imagine that the export would be
at or near that number

Our admins here at Site B only run one project per RTC instance (not
sure exactly what the topology is, but I know they make extensive use
of virtualisation) which gives them the flexibility to import and
export projects at will. It sounds to my non-expert understanding
like the setup at Site A is to run multiple projects on an RTC
instance, which causes the difficulties listed above. I very much
doubt that this small project has 8GB of content, for instance, so it
appears that they can only export a whole bundle of projects
together.
Hence the widespread outage, and the concern about accessibility as
they would be shipping us the code for projects unrelated to us.

I have no idea where to go from here. Is the mass export with its
associated problems our only option? The subtext is that this might
require some political (management) will to achieve. Can anyone
suggest an alternative approach I could pass on to the Site A admins
which would allow them to extract only the content for our project?
Any other ideas?

Cheers,

Pete

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.