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

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

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

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

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

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